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PREFACE 


This manual is directed to the user who intends to modify the TX990 operating system. It is 
assumed the user is experienced in 990 assembly language and has access to the source code for 
the TX990 operating system. This manual describes the internal data structures and organization 
of the operating system. The following is an abstract for each section of this manual. 

I Introduction — Describes the scope of the TX990 operating system. 

II TX990 Structure and Control — Describes the internal structure and control flow- of 

the TX990 operating system. It is necessary to understand the control flow before 

modifying the system, so that the impact of any modifications on the system is 
predictable. 

III Privileged Supervisor Call Blocks - Describes the privileged supervisor call blocks. This 
section also discusses the purpose of each supervisor call, and how it is used. 

IV Modifying TX990 — Explains some of the more common reasons for modifying the 

system. Describes the considerations that must be taken into account before or during 

the modification of the system. Explains in detail how to modify the operator 

communication package (OCP), write device service routines (DSR), write extended 
operations (XOP) and supervisor calls. 

V Data Structures — Describes each data structure and the relationship between the data 
structure and the operating system. This section explains how the system uses the data 
structure to control system functions. 

VI Module Description — Explains the purpose and function of each module so that a 
user can make intelligent choices on component parts of the TX990 operating system. 
Each module has a brief functional description and lists other modules that must be 
included in order to utilize the module effectively. 

The following documents contain information referenced in this manual: 

Title Part Number 

Model 990 Computer TX990 Operating System 946259-9701 

Programmer's Guide (Release 2) 

Model 990 Computer Assembly Language 943441-9701 

Programmer’s Guide 
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SECTION I 

SCOPE OF THE TX990 OPERATING SYSTEM 


1.1 INTRODUCTION 

The purpose of the TX990 operating system is to provide task scheduling functions, memory 
management, interactive debugging aids, interactive operator control, and a basic disc file 
management package. The TX990 operating system is designed to be upward compatible at the 
task level with DXIO, release 3.0. TX990 supervisor calls are a subset of the DXIO, release 3.0 
supervisor calls. TX990 is modularly designed so that modules may be selected according to the 
needs of the user to customize the TX990 operating system. TX990 is a multitasking, single user 
operating system. Many tasks may execute simultaneously; but in the single dynamic task environ- I 
ment, there is no memory resource scheduling within the operating system. The user must be aware 1 
of which tasks require the dynamic memory area, and must execute only one of these tasks at a 
time. Memory resource scheduling is provided when the multiple dynamic tasks option is selected. I 
Since there is no resource scheduling of certain hardware devices, such as the line printer and card 
reader, conflicting requests for these devices must be resolved by the user by either generating these 
devices in record mode during system generation, or by scheduling the tasks so they do not conflict 
on resource requests. The user is also responsible for preventing a task from inadvertently altering 
memory outside of its address space and destroying other tasks or the operating system. 
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SECTION II 
TX990 STRUCTURE 


2.1 TX990 OPERATING SYSTEM CONTROL FLOW 

f operating system begins and ends with the task. When a task is bid the 
S . '1 'he active task queue for that taskV priority ^ 

Sk ifthe^L'k rt ' 'h' ‘“h schedulei begins the execution onha’t 

^ ^ desires a particular service of the operating system, a supemsor call tSVC-i i<! 
issued. The supervisor call interface routine decodes the Sv6 cLe, the app^op^Lte SVC rluW 
selected, and control is transferred to it. Upon completion of the SVC or the discovery of an 
thT'/ar transferred to a common exit routine. The common exit routL XeTctlte 
immediately, end the task’s time slice and put the task at the end of the appropriate 
pnonty s active task queue, or suspend the task, depending upon the particular SVC 

If an I/O operation generates an interrupt for any reason, control is transferred to the appropriate 
interrupt handler, and from there to the common exit routine. If a task is interrupted, control is 
returned to it after interrupt processing is complete. 

If a fatal error occurs during the processing of an SVC or while a task is executing, control is trans- 
ferred to the end action routine supplied by the task. If the task does not have an end action 
routine, the diagnostic task (DTASK) will be executed. DTASK displays an error message and 
performs the necessary housekeeping functions required to terminate the task. Control is then 
transferred to the task scheduler where the task is terminated. See figure 2-1. 

2.2 TASK SCHEDULER 

The task scheduler uses a priority scheme with four levels and maintains a list of active tasks at 
ach pnonty level. A task is added at the end of the active task list in each of the following cases: 

® When the task is placed in execution (bid). 

• When the task is reactivated by another task. 

• At the completion of a time slice. 

• At the completion of a supervisor call that caused the task to be suspended. 

‘f. " of a task, beginning when the scheduler passes control to the 

task. A time slice ends when any of the following occurs.* 

• tfme expiration of the maximum time period allowed 

• The task executes a supervisor call to suspend the task. 

• The system suspends the task to await completion of an I/O operation. 

i?TeneratS^"^ Period allowed for a time slice is a system parameter specified when the 

the currently executing task completes a time slice, the task scheduler passes control to the 
oldest task on the active list for the highest priority (0), except as described later. If there is no task 

“ceSIr'iSriol '-i5h«; prio“ 
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Figure 2-1. TX990 Operating System Control Flow 
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To avoid completely locking out low priority tasks, there is a maximum number of consecutive 
time slices (weighting factor) for each priority level. When this number of time slices has been used 
by a priority level, the oldest task on the active list for the next lower priority is allowed a time slice 
before the higher level again has control. The action of passing control can propagate through mul- 
tiple priority levels when the weighting factors have been used up simultaneously. Therefore, all 
priority levels will be guaranteed at least occasional time slices. The maximum number of time slices 
for each priority level are system parameters defined during system generation. 

2.3 MEMORY MANAGEMENT 

User memory is maintained by the memory management routine (module MEMSVC for a single 
dynamic task or DMEMSVC for multiple dynamic tasks). For the single dynamic task system, 
memory is not actually allocated. A pointer to the available memory block, immediately following 
the dynamic task, is returned to the task requesting memory. All tasks requesting memory will be 
returned this same pointer. For multiple dynamic tasks, the user memory is actually allocated to 
the requesting task. Each task requesting memory will receive a different block of memory. This I 

memory is returned to the available memory pool when the task terminates or issues Return I 

Memory SVC. | 

(module TBUFMG) is used to service the system requests for buffers contained in I 
system generation. See paragraph 5.1 for a description of | 
TXDATA.). The buffer manager has queues of different sizes of memory blocks. These blocks of 
memory are used as buffers for LUNO assignments, blocking buffers, intertask communications, 
messages, communication package buffers, etc. 


2.4 SUPERVISOR CALL INTERFACE 

A supervisor call is the method by which the user task requests that a particular service be 
performed by the operating system. TX 99 Q implements supervisor calls by using the extended 
f f hardware decodes the XOP level as an index into a brarichlable 
(defined dimng system generation and initialized during the loading procedure) that contains the 
workspace and entry address of the XOP processor. All level 15 XOPs are channeled • to a 
processor in module TXROOT. TXROOT decodes the XOPs operation code, which is the first 
supervisor call block, and branches to the appropriate supervisor call processor. 
rXROOT also has a common return routine for all the supervisor call processors which provides 
three return entry points that either reactivate the task immediately, end the task’s time slice 
and put the task at the end of the active queue, or suspend the task. 


2.5 INPUT/OUTPUT OPERATIONS 

supervisor calls with a supeiwisor call code of 00, ^ are handled by module 
iOSWR The I/O supervisor call processor uses the LUNO number obtained from the supervisor 
call block to detennine whether the I/O is directed to a device or a disc file. When the I/O is 
directed to a device, the appropriate device seixice routine is called. When the device service 
routine completes the operation, a routine in lOSUPR, ENDREC, is called to perform system 
housekeeping. Control is returned to the calling task through the common return routine in 
TXROOT. When the I/O is directed to a disc file, the calling task’s Task Status Block (TSB) is put 
on a file management queue and the appropriate file management task is bid. The file management 
task removes the TSB from the queue, performs the I/O service, and places the TSB back on the 
active queue. If it has no other queued services to resolve, the file management task terminates. 


2.6 FILE MANAGEMENT TASKS (FMPI , FMP2, FMP3, FMP4, FUR, VOLUME) 

File management tasks are bid by module lOSUPR when an I/O operation is directed to a disc file. 
A tile management task removes TSBs requests from a queue and services the I/O requests It con- 
tinues to service the queued requests until the queue is empty. At that time, the file management 


I 

I 


Change 1 


2-3 


Digital Systems Division 



task terminates. There are four file I/O tasks: FMPI, FMP2, FMP3, and FMP4 (Task IDs FOio, 
FI 16 , F2[6, F3j 6). There must be a file I/O task for each disc drive in the hardware configuration 
for which file support is desired. The fifth task is a file utility task, FUR (Task Bfe). The file utility 
task creates, deletes, compresses, and changes the names of files. The sixth task, VOLUME (Task 
Ci6), locates the volume and associates with it a diskette drive and the file management task for 
that drive. 

2.7 OPERATOR CONTROL, TASK OFi 6 

TX990 has an operator communications package (OCP) that allows the user to Interface with the 
operating system to control, load and execute tasks, manipulate LLJNOs, and debug. OCP is an 
optional task (Task F, 5 ) that must be linked to the system so it can access system data 
structures. OCP is organized so that the user may easily write additional OCP commands for a 
customized TX990 operating system. (Section IV describes this process.) The module OCPPRC is 
the control module for OCP commands. It decodes the call and branches to a command 




Change 1 


24 


Digital Systems Division 



944776-9701 

processor. When the command processor has completed its task, it branches to a common return 
point in OCPPRC. The command processors are packaged in discrete modules so that the user may 
select only those commands necessary for his dedicated application using a customized TX990 
operating system. 

2.8 DIAGNOSTIC TASK (DTASK), TASK 0D,g 

The diagnostic task is an optional, but highly recommended, linked-in TX990 system task. It has 
a task I.D. of ODjg and is activated by error detection logic in the TXROOT module. 

When a task commits a fatal error and its end-action word is less than 16jo, the TXROOT error I 

logic removes the task status block from its active queue and puts it on the diagnostic queue, 
while changing the task’s state to “On Diagnostic Queue”. After this has been done, the 
diagnostic task is bid. 

DTASK removes a queued TSB and prints the task I.D., error code, and the workspace pointer 
(WP), status register (ST), and program counter (PC) of the task when the error occurred. The 
printed PC value usually points to the instruction following the one that caused the error. After 
the message has been printed, the diagnostic task sets the task status block’s kill task flag and 
returns the task to its active queue to be killed by the scheduler. Before termination, DTASK 
checks for more entries on its queue. 

In a TX990 system with DTASK, a task committing a fatal error causes a message to be printed 
on LUNO 0. A TX990 system without DTASK places an error task on the diagnostic queue and 
takes no other action. In such a system, a task that is terminated with a fatal error remains on 
the diagnostic queue, in the On Diagnostic Queue” state. Should the diagnostic task commit a 
fatal error (a system malfunction), the message “HELP” is printed on the system console. 

2.9 INITIAL START TASK (STASK), TASK 10,6 

The TX990 startup task is a linked-in system task that runs only at initial system startup. Its 
purpose is to demonstrate that the system is up and running. STASK prints the memory size of 
the machine and the size of the dynamic task area on the system console. The startup task is 
normally linked after the TXEND module, physically placing it in the dynamic task area. It is 
overlaid by any user software that is loaded, and therefore does not add to the size of TX990. 

For this reason, it is recommended that STASK be included in all TX990 systems, except 
dedicated application systems. 

In the normal TX990 configuration, STASK has a task I.D. of 10,6 and executes only on the 
initial start of the operating system. If it is desired that STASK be executed on a manual restart 
of TX990, it is necessary for it to be linked before TXEND and for a task I.D. other than 10,6 
to be assigned to it during system generation. 

2.10 SINGLE DYNAMIC TASK LOADER ROUTINE | 

The loader routine loads the object code, from the file or device assigned to LUNO 2, into the 
dynamic task area. The task that is loaded has the task I.D. of 10,6- A user task that is to use 
the loader routine must be linked to the operating system, since the object program is loaded 
into the dynamic task area. The user task must reference three labels: LDRDAT, LDRFLG, and 
LOADER. LDRFLG is a lock-out flag (see Section V). When the flag is set, only the user’who 

set it may use the task loader. Once the flag is set, the user task must initialize a parameter 
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BYTE 0 
BYTE 2 


ADDRESS OF BUFFER 

PRIORITY 

LEVEL 

PRIVILEGE 

FLAG 


L(rJf /^1 
Lut fLX 


^ parameter block. Bytes 0 and 1 contain the address of an 80-character 

h !h^ ^ loader. Byte 2 contains the priority level (0-3) 

at Which the task will run. Byte 3 contains the privilege flag: 0 indicates the task is to be loaded as 

bS^LDlfnAT^*" privileged. Once the TSKLDR parameter 

ck, LDRDAT is initialized by the user task, the user task must branch to the loader entry point 
which IS calbd ‘ LOADER” (via a BLWP instruction). When the task loader completes 

n th h t Tt? to the user task. The task loader returns an error code 

in the left byte of the calling task s register 0. 

The module IMpLDR must be included to load a task from a program image file. If the program 
file being loaded has overlays, the task loader assigns LUNO >10 to the program file. This is used 
overlay °oShiV°^^ routine to load overlays. See the link editor manual for details on automatic 

The following coding example illustrates the user of the task loader routine. LUNO 2 is already 
assigned to an object file. ■ oncauy 



REF 

LDRDAT 


REF 

LDRFLG 


REF 

LOADER 

WAIT 

* 

DATA 

200,40 

BUF 

* 

BSS 

80 

LI 

ABS 

@LDRFLG 


JLT 

L2 


XOP 

©WAIT, 15 


IMP 

LI 

L2 

LI 

R2,LDRDAT 


LI 

R1,BUFF 

* 

MOV 

R1,*R2+ 


LI 

Rl>0380 

* 

MOV 

R1,*R2 


BLWP 

©LOADER 


MOVB 

RO.RO 


JNE 

ERROR 


TIME DELAY SVC BLOCK 

80-CHARACTER BUFFER 

SET THE SEMAPHORE 
IF SUCCESSFUL GO SET UP LDRDAT 
ELSE WAIT AND TRY AGAIN 

INITIALIZE THE PARAMETER BLOCK 

PUT THE BUFFER ADDRESS IN BYTE 0 OF 
LDRDAT 

SET THE PRIORITY TO LEVEL 3, 

AND MAKE THE TASK PRIVILEGED 

CALL THE LDR ROUTINE 
CHECK THE ERROR CODE 
IF ERROR THEN EXIT 
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2.U MULTIPLE DYNAMIC TASK AND PROCEDURE LOADER 

TX990 optionally supports the installation of multiple dynamic tasks and procedures at execution 
time. These tasks and procedures are loaded by system routines callable by programs linked with 
the operating system. Dynamic task >10 can still be loaded by the same interface as described in 
paragraph 2.10. System routines arc provided to install task, install procedure, delete task, and 
delete procedure. 

The modules DYNTSK, DTSKLDR (replaces TSKLDR), and DMEMSVC (replaces MEMSVC) must 
be included to support these routines. Since these routines may not be executed concurrently, the 
linked-in user program must test and set the loader lock-out flag, LDRFLG, to gain exclusive access 
to the loader routines. LDRFLG should be reset when the load or delete operation is complete. 
The following illustrates the calling sequence: 


LOOP 

ABS 

©LDRFLG 

TEST AND SET FLAG 


JLT 

CALL 

IF BUSY 


SVC 

©DELAY 

THEN DELAY 


JMP 

LOOP 

AND RETRY 

CALL 

FQU 

$ 

ELSE 


BLWP 

©ITASK 

CALL TASK LOADER 


DATA 

ITBLK 

CALL BLOCK 


SETO 

©LDRFLG 

RESET LOADER FLAG 


The calling program must pass a call block, much like a supervisor call block, to the system routine. 
The format of each block is described in the following paragraphs. 

2.1 1 .1 INSTALL TASK CALL BLOCK. The install task routine requires the following data block: 

BYTE 
O 
2 
4 
6 


8 


0 

ERROR CODE 

LUNO 

TASK ID 

FL^.GS 

PRIORITY 

PROCl ID 

0 

EXTRA MEMORY 






L 


The install task call block data is: 

Byte 0 — Not used. 

Byte 1 — Error code returned by the system. 
Byte 2 — LUNO assigned to input file. 

Byte 3 — Installed task ID. 

Byte 4 — Flags. 

Bit 0 Privileged task. 

Bit 1 Do not rewind LUNO. 

Byte 5 — Task priority. 


Change 1 


2-6 


Digital Systems Division 



944776-9701 



Byte 6 - Procedure ID. 


Byte 7 - Reserved (must be zero). 

Bytes 8 - 9 - Allocate extra memory for task. 

The LUNO must already be assigned to the file to be loaded. Errors are returned for duplicate task 
ID, insufficient memory, and nonexistent procedure. 

2.11.2 INSTALL PROCEDURE CALL BLOCK. The format of the install procedure block is as 
follows: 

BYTE 
0 
2 

The install procedure call block data is: 

Byte 0 - Not used. 

Byte 1 — Error code returned by the processor. 

Byte 2 - Input LUNO. 

Byte 3 — Procedure ID. 

The LUNO must already be assigned to the file to be loaded. Errors are returned for duplicate 
procedure ID and insufficient memory. 

2.11.3 DELETE TASK CALL BLOCK. The format of the delete .task data block is as follows: 

BYTE 
0 
2 

The delete task call block data is: 

Byte 0 - Not used. 

Byte 1 - Error code returned by the SVC processor. 

Byte 2 — Reserved (must be zero). 

Byte 3 — ID of task to be deleted. 

An error is returned if the task is not terminated. 

2.11.4 DELETE PROCEDURE CALL BLOCK. The format of the delete procedure data block is 
the same as for the delete task data block, except ID refers to procedure ID. An error is returned if 
the procedure is attached to a task. 


0 

ERROR CODE 

0 

TASK ID 


0 

ERROR CODE 

LUNO 

ID 


Change 1 


2-6A 


Digital Systems Division 




The control program is the control module for the TXDS utility programs. It decodes the user’s 
entries for program name, I/O specifications, and options. It then loads and branches to the 
specified utility program. When the utility program terminates, the utility executes an end program 
supervisor call (Ibjg) which activates the rebid task. 
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2.13 REDID TASK 

The system rebid task is the task that is activated whenever an end program supervisor call is 
issued. For standard TX990/TXDS systems, the TXDS control program is defined as the rebid 
task. The control program is defined to have the task I.D. of 16,6. The user may wish to 
designate another task as the rebid task. This can be accomplished in the following manner. 

1. Place the following statements in the new rebid task. 

DEF REDID 
REDID EQU ID*>100 

Where ID = The task I.D. of the new rebid task. 

2. When the TXDS control program is included in the system, link the object code for 
the new rebid task before the module CNTROL. 
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SECTION III 

PRIVILEGED SUPERVISOR CALLS 


3.1 GENERAL 

TX990 contains a number of supervisor calls that can only be made by tasks which are 
privileged. This insures that the user program cannot easily gain access to internal operating 
system structures and inadvertently modify them. 

3.2 GET SYSTEM TABLE 

The Get System Table supervisor call (21i6) returns to the caller the address of the system table 
in which pointers to data structures within TX990 are located. See Section V for a description of 
the system table. This supervisor call should be used only by system tasks that require access to in- 
ternal data structures. A program using this SVC will not be compatible with any other 990 opera- 
ting system. 

3.3 DIRECT DISC I/O 

3.3.1 INTRODUCTION. To maintain disc file integrity and security, and to control disc alloca- 
tion, direct disc I/O is reserved for use by TX990 system tasks. System tasks are those which are 
executed in the privileged mode. 


I/O to disc is controlled by an extended supervisor call block (SCB) as shown in figure 3-1. See the 
Model 990 Computer TX990 Operating System Programmer’s Guide (Release 2), number 
946259-9701, for a description of the standard supervisor call block. As with any other device, 
access is through a LUNO assigned to the disc. TX990 has a reserved system (nonreleasable) 
LUNO (starting at EOj^) for use by system tasks, such as file management and file utility, for 
each disc unit configured in the system. Action taken on the I/O opcodes is described in 
table 3-1. Discs are classified as record-oriented devices by TX990 and need not be opened or 
closed after or before I/O operations. 
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SPECIFIED 

7 - ALLOCATION UNIT I/O 
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Figure 3-1. Direct Disc I/O SCB 
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Table 3-1. Direct Disc I/O Opcodes 


Opcode 

Function 

Action 

0,6 

Open 

Ignored (device type returned) 

1,6 

Close 

Ignored 

2,6 

Qose EOF 

Ignored 

3,6 

Open Rewind 

Ignored (device type returned) 

4,6 

Close Unload 

Ignored 

5,6 

Read Format 

Return disc/track format 

6,6 

Forward Space 

Ignored 

7,6 

Back Space 

Ignored 

8,6 

Write Format 

Formats track 

9,6 

Read ASCII 

read 

A,6 

Read Direct 

read 

B,6 

Write ASCII 

:]^ftoca^iorT°bascd write 

C,6 

Write Direct 

took’baeed write 

D,6 

Write EOF 

Ignored 

E,6 

Rewind 

Ignored 

F,6 

Read Format 

Return disc/track format 

10,6 

Write Deleted Sector 

Write deleted code on sector 


Before tracks on a disc can be used for data storage using file management, they must be formatted. 
This may be done by a utility program called :BACKUP/SYS. 

Track numbering runs sequentially from zero to the maximum track. Physical read and write 
operations must start at sector boundaries, but need not include an entire sector, and may cross 
sector boundaries. 

Records must be read and written from the beginning but need not be read or written to the 
end. Short records written to a disc cause the remainder of the physical record to be zero filled. 
Sectors are numbered from zero on each physical track. 
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3.3. 1.1 Direct Disc Call Block. The direct disc supervisor call block (SCB) is sixteen 
as shown in figure 3-1 . The SCB has the following format: 


bytes long, 


Byte 0 - I/O SVC code. 

Byte 1 — Error code returned by TX990. 


Byte 2-1/0 OPCODE contains the code of the operation to be performed. 

Byte 3 — LUNO. The logical unit assigned to the disc. 

Byte 4 — SYSTEM FLAGS. System status in an I/O operation. 

Bit 0 Busy. Set to one when operation is initiated and to zero upon completion. 

Bit 1 Error. Set to one when operation terminates in error. Byte 1 contains the 

error code. 

Byte 5 — USER FLAGS. Set by user prior to operation. 

Bit 0 Initiate I/O. User sets to one for an Initiate Call. When zero, task is sus- 

pended until I/O is complete. When one, system initiates operation and 
returns control to the task. 

Bits 1-5 Not used. 


Bit 6 Sector Length Specified. Set to one if user wants a different sector size 

The size, in bytes, is in byte 14 of the SCB. Also set to one to indicate 
that a logical track I. D. is specified (in byte 14 of the SCB) on a write for- 
mat operation. 

Bit 7 Allocation Unit I/O. Set to one for allocation unit I/O. Set to zero for 

physical track I/O. 

Bytes 6 7 — BUFFER ADDRESS. Address of data buffer. Aligned on a word boundary. 

Bytes 8-9 - RECORD LENGTH. Maximum number of characters to be entered. 

Bytes 10-1 1 - CHARACTER COUNT. For input operations the number of characters actually 
input. For output operations, the number of characters written. 

Bytes 12-13 - TRACK ADDRESS. Tlie physical track address on the disc for track I/O The 
allocation unit address for allocation unit I/O. 

Byte 14 - SECTORS PER RECORD. This field is used in several different ways. On format 
track it is the logical track I. D., if user flag bit 6 is set, and a one (1) is returned. On 
track-based read or write, it is a physical sector length in bytes. 

Byte 15 - SECTOR ADDRESS. The sector within a physical track or an allocation unit. 

(0-S) 
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3.3.2 TRACK-BASED I/O 

3.3.2.1 General. Track-based I/O is specified wlien bit 7 of the SCB user flag byte (byte 5) is set to 
zero. This mode of I/O is used to access tlie disc in its physical configuration of tracks and sectors. 
Tlie commands are treated as described below. 

3.3. 2.2 Read Format (5,6 and F,6). This command requires at least 5 words of buffer space. 
SCB record length, cliaracter count, sectors per record, track address, and sector number are 
ignored. Ten bytes of track-based disc and track-based data are returned in the user buffer as 
shown in figure 3-2. The track-based read format data is: 

Bytes 0-1 — WORDS/TRACK. Number of unformatted words on each track of the disc. 

Byte 2 — SECTORS/TRACK. Number of sectors on each track of the disc. 

Byte 3 — OVERHEAD/RECORD. Number of words required for each formatted record on 
a track. 

1 

Byte 4 — # OF HEADS. Number of heads addressable on the disc unit. 

Bits 04 

Bytes 4-5 — # OF CYLINDERS. Number of cylinders addressable on the disc units. 

Bits 5-15 

Byte 6 - SECTORS/RECORD. Number of sectors spanned by each record on the track. 

Byte 7 — RECORDS/TRACK. Number of records the track is fonnatted into. 

Bytes 8-9 — WORDS/RECORD. Length of records on track (in words). 


3.3.2.3 Write Format (8,6). This command requires an SCB record length and track address. It 
formats the addressed track to the given record length and returns the resulting number of 
sectors per record in byte 14 of the SCB. User buffer, character count, and sector number are 
ignored. 


0 15 


WORDS PER TRACK 


SECTORS PER 1 

rRACK 

OVERHEAD PER RECORD 

#HEADS 

# CYLINDERS 

SECTORS PER RECORD 

RECORDS PER TRACK 

1 WORDS PER RECORD 
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Figure 3-2. Track-Based Read Format Data 
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3. 3. 2.4 Read Direct (Aig), Write Direct (Cje). These commands transfer data to/from the user | 
buffer by standard TX990 conventions. The SCB record length determines the maximum number 
of characters received during a read and the SCB character count determines the number of charac- 
ters transmitted during a write. No distinction is made between ASCII and direct I/O transfers, all 
are binary data. Data transfers can span records and tracks. 


Data is always transferred on a word basis, that is, buffer addresses and byte counts are 
truncated to even numbers. Note that the complete disc address of track number, sector number, 
and track format (sectors per record) is required for data transfers. 

3.3.3 ALLOCATION UNIT-BASED I/O 

3.3.3. 1 General. Allocation unit-based I/O is specified when bit 7 of the SCB user flag byte is 
set to one. This mode of operation is provided for the convenience of the TX990 file 
management package. Special applications programs that do direct disc I/O usually use track- 
based operations. 


When operating in the allocation unit mode, the DSR restructures the physical layout of the disc 
to a format more easily used by TX990 file management. This capability allows the file 
management system to be implemented without any prior knowledge of the characteristics of the 
device to be used for file storage, other than the fact that it is a random-access, mass storage 
device. 


With track-based I/O, the disc is addressed in terms of track and sector. For allocation unit 
operations, the disc is addressed in terms of allocation unit and physical record. 

The AU is the basic unit of file space allocation used by file management. An allocation unit is a 
set of 6 physical records: i.e., sectors, located on one or two tracks of a diskette. The 6 records 
composing a single AU are NOT CONTIGUOUS (table 3-2). Thirteen AUs fill 3 tracks on the 
diskette. Table 3-2 lists the addresses of each of the 13 AUs on tracks 0, 1, and 2. The sequence 
of sectors repeats throughout the remaining tracks on the diskette. Table 3-3 is a sampling of 
initial records for other AUs on the remaining tracks. 


3.3.3. 2 Read Format (Sj* and F,6). The Read Format command returns bytes of 

information to the calling program’s buffer, as shown in figure 3-3. A disc to be used with 
TX990 is always formatted to the number of sectors per record returned by this call. The 
allocation unit-based read format data is: 

Bytes 0-1 - BYTES PER RECORD. The number of bytes per physical record on the disc. 

Bytes 2-3 - FCB SIZE. The number of bytes needed to contain the File Control Block 


Bytes 4-5 - RECORDS PER ALLOCATION UNIT. Tlie number of physical records in each 
allocation unit. 

Bytes 6-7 - MAXIMUM NUMBER OF ALLOCATION UNITS. The number of allocation 
units available on the disc. 

Bytes 8-11 - DIRECTORY START AND SIZE. The allocation unit where the directory 
begins (2 bytes) and its length in physical records (2 bytes). The directory always starts 
at physical record 0 of its allocation unit. 
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Bytes 12-15 - ALLOCATION TABLE START. The allocation unit (2 bytes) and physical 
record (2 bytes) where the disc allocation table starts. 

Bytes 16-17 - BAD ALLOCATION TABLE START. The physical record on the same alloca- 
tion unit as the Allocation Table, bytes 12-13, where the disc allocation table for bad 
allocation units starts. 

Bytes 18-21 - DEVICE INFORMATION BLOCK START. Tlie allocation unit (2 bytes) and 
physical record (2 bytes) where the disc device information block is located. 

Bytes 22-25 - HASH TABLE START. Tlie allocation unit (2 bytes) and physical record 
(2 bytes) where the directory hash table begins. This field is currently unused. 

Byte 26 — DISC TYPE. A unique code for each type of disc. 

Byte 27 — Unused. 


• Table 3-2. Allocation Unit Record Assignments 


AU, Record 

Track, Sector 

AU, Record 

Track, Sector 

AU, Record 

Track, Sector 

0.0 

0,4 

4.2 


8,4 

2,4 

0. 1 

0, 10 

4.3 

1, 10 

8,5 

2, 10 

0,2 

0, 16 

4.4 

1, 16 

9,0 

2, 16 

0,3 

0, 22 

4,5 

1, 22 

9,1 

2, 22 

0,4 

0, 2 

5,0 

1.2 

9,2 

2,2 

0, 5 

0, 8 

5,1 

1.8 

9,3 

2,8 

1.0 

0, 14 

5,2 

1,14 

9,4 

2, 14 

1.1 

0, 20 

5,3 

1,20 

9, 5 

2, 20 

1.2 

0,0 

5,4 

1,0 

10, 0 

2,0 

1,3 

0,6 

5.5 

1.6 

10, 1 

2.6 

1.4 

0, 12 

6, 0 

1, 12 

10, 2 

2, 12 

1, 5 

0, 18 

6, 1 

1, 18 

10,3 

2, 18 

2,0 

oT24 

6,2 

1,24 

10,4 

2, 24 

2,1 

0, 5 

6, 3 

1.5 

10, 5 

2,5 

2,2 

0, 11 

6,4 

1, 11 

11, 0 

2, 11 

2,3 

0, 17 

6, 5 

1,17 

11, 1 

2, 17 

2,4 

0, 23 

7,0 

1, 23 

11, 2 

2, 23 

2, 5 

0.3 

7. 1 

1,3 

11.3 

2,3 

3,0 

0,9 

7,2 

1,9 

11,4 

2,9 

3. 1 

0, 15 

7,3 

1, 15 

11, 5 

2, 15 

3,2 

0, 21 

7,4 

1,21 

12,0 

2, 21 

3,3 

0, 1 

7,5 

1, 1 

12, 1 

2, 1 

3,4 

0,7 

8,0 

1.7 

12, 2 

2,7 

3, 5 

0, 13 

8, 1 

1, 13 

12, 3 

2, 13 

4,0 

0, 19 

8, 2 

1, 19 

12,4 

2, 19 

4, 1 

0, 25 

8, 3 

1, 25 

12, 5 

2,25 
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Table 3-3. Sampling of AUs on a Diskette 


AU 


13 

26 

39 

52 

65 

78 

91 

104 

117 

130 

143 

156 

169 


BYTES 


BYTES PER RECORD 

FCB SPCET 

RECORDS PER AU 
MAXIMUM # AU’S 
DIRECTORY START AU 
•DIRECTORY REC 

ALLOCATION START AU 
ALLOCATION START REC 
BAD ALLOC. START REC 
DEV INFO BLK AU 
DEV INFO BLK REC 
HASH TABLE AU 
HASH TABLE REC 

DISC TYPE [ UNUSED 
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0-1 

2-3 

4-5 
6-7 
8-9 
10-1 1 

12-13 

14-15 

16-17 

18-19 

20-21 

22-23 

24-25 

26-27 


Track, Sector 

AU 

Track, Sector 

3.4 

182 

42,4 

6,4 

195 

45,4 

9,4 

208 

48,4 

12,4 

221 

51,4 

15,4 

234 

54,4 

18,4 

247 

57,4 

21,4 

260 

60,4 

24,4 

273 

63,4 

.27,4 

286 

66,4 

30,4 

299 

69,4 

33,4 

312 

72,4 

36,4 

325 

75,4 

39,4 

333 

77,10 


Figure 3-3. Allocation Unit-Based Read Format Data 
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3.3.5.3 Write Format (8,6). The Write Format command is not defined for allocation unit-based 
I/O. 

i 3. 3. 3.4 Read ASCII (9,6), Write ASCII (B,6). The allocation unit-based read and write operations 

are identical to the track-based operations previously described provided that all references to 
“track” are changed to “allocation unit” and all references to “sector” are changed to “physical 
record”. 

The number of sectors per record is fixed for allocation unit I/O, therefore this field in the SCB is 
ignored. 

3.3.4 FLOPPY DISC SPECIAL OPERATIONS. 

3.3.4. 1 General. There are certain operations that can be done on the floppy disc that are not 
generally supported on other discs. These operations should be avoided in any software intended 
to be transferred to other disc types. 

f^3.3.4.2 Sector Length Specified. The floppy disc controller allows the length of a sector to be 
specified, the allowable range being 2 to 128 bytes. The sector length must be even, and is set to 
128 bytes by the DSR unless specifically overridden. To specify the sector length for an I/O 
operation, bit 6 of the SCB user flags is set to a one and the number of characters per sector is 
placed in byte 14 of the SCB (sectors/record is always one for the floppy disc and the DSR 
normally ignores this field). The sector length may be specified only for track-based read and 
write operations. 

3.3.4.3 Logical Track Specified. The floppy disc controller allows a track to be formatted with 
an I.D. other than the physical track the head is positioned over. This capability is necessary to 
format a diskette that is to be used for data interchange with certain other vendors’ equipment. 

The DSR always writes the track I.D. to match the physical track unless specifically overridden. 
To specify the track I.D. to be written, bit 6 of the SCB user flags is set to a one and the track 
I.D. is placed in byte 14 of the SCB. The track I.D. may be specified for write format operations 
only. 

3.3.4.4 Write Deleted Sector (10,6 ). The floppy disc controller can “delete” a sector by writing 
a special data pattern on it. To delete a sector, I/O opcode 10,6 is executed with the track and 
sector address specified. Applies to track-based I/O only. 

3.3.4.5 Floppy Disc Format Restrictions. The floppy disc can be formatted only in the one 
sector per record configuration. For this reason, the DSR always ignores this field in the SCB. 
For software to be transportable to other disc types, it is desirable that this field be filled in 
correctly for track-based I/O, even though it is not used. 

3.3.4.6 Sector Interleaving. To more closely match the I/O rate of the floppy disc with the 
execution rate of software on the 990, the disc sectors are interleaved. Tliis interleaving is in 
effect only for allocation unit-based operations, and is a simple mapping of logical to physical 
sectors. The mapping used is shown in table 3-4 and is illustrated in tables 3-2 and 3-3, and is such 
that four or five logical sectors pass by the read/write head for every disc revolution. 
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Table 3-4. Floppy Disc Sector Interleaving 


Logical 

Physical 

Logical 

Physical 

0 

4 

13 

5 

1 

10 

14 

11 

2 

16 

15 

17 

3 

22 

16 

23 

4 

2 

17 

3 

5 

8 

18 

9 

6 

14 

19 

15 

7 

20 

20 

21 

8 

0 

21 

1 

9 

6 

22 

7 

10 

12 

23 

13 

11 

18 

24 

19 

12 

24 

■ 25 

25 


3.3.5 DISC DSR ERRORS. The DSR can return the following status codes: 

Code Meaning 


00 

02 

04 

06 

11 

12 

15 

19 


No error 

Invalid I/O opcode 

Record lost due to power failure 

Time-out or abort 

I. D. error 

No address mark found 
Data error 
Disc not ready 
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Code 

Meaning 

lA 

Disc write-protected 

IB 

Unit check 

1C 

Invalid disc address. 

ID 

Seek error 

IE 

Deleted sector detected 


3.3.6 DISC READ FORMAT DATA (DISKETTE) 


3.3.6. 1 Track-Based Data. 


Words per track: 

1664 

Sectors per track: 

26 

Overhead per record: 

0 

Number of heads: 

1 

Number of cylinders: 

77 

Sectors per record: 

1 

Records per track: 

26 

Words per record: 

64- 


3.3.6.2 Allocation Unit-Based Data. 


Bytes per record: 128 

FCB size (bytes): 96 

Records per AU : 6 

Number of AUs: 333 

Directory start/size (AU/rec): 5,6 

Allocation start (AU/rec); 4,1 

Bad allocation start (rec): 2 

Device info blk (AU/rec): 4,0 

Hash table start (AU/rec): 0,0 

Disc type: 0 


3-10 


Digital Systems Division 




944776-9701 


SECTION IV 
MODIFYING TX990 


4.1 GENERAL 

The following sections describe the modifications to the TX990 operating system most com- 
monly made by users. These modifications include adding new XOP routines, adding new SVC 
processors, adding device service routines (DSR) for nonstandard devices, and adding new 
processors to the operator communication package (OCP). To make any of these additions, the 
user must code and assemble modules to support these functions and include the object modules 
in the system, at system generation time. For a detailed discussion about the inclusion of user 
modules during system generation, see the TX990 Operating System Programmer’s Guide. 

TX990 is designed as a general purpose operating system that can be tailored to fit the user’s 
needs. In some cases, the user may require support from the operating system that is not 
provided in the standard configuration. This support can be supplied by user-generated XOP 
routines or SVC processors (XOP 15). Another use for a new XOP or SVC processor is to 
implement a commonly used subroutine that the user does not wish to link with each program. 

TX990 is designed to be a total system, but is constructed in a way that allows the user to build 
a dedicated system. In doing so, the user may use devices not directly supported by the TX990 
operating system. To support these devices, the user writes a DSR that conforms to a set of 
standards and modifies the standard physical device table (PDT) to support the DSR. 

There are a few guidelines that should be followed when modifying the system. Enhancements to 
the system should be made as discrete modules to maintain the modularity of the operating 
system. When system tasks are added, they need not be linked with the system itself, but can 
use the Get System Table supervisor call to obtain the pointers to the system data structures. 
This allows users to link the task with the memory resident portion of the operating system or 
to maintain the task on disc. All ptilities should be written so that the utility may either be 
linked with the memory resident portion of the operating system or be disc resident. 

4.2 SUPPORT OF NONSTANDARD DEVICES 

Before generating code to support a nonstandard device, the user must have thorough under- 
standing of the following information: 

1) Device interface - Most devices have a set of common characteristics, but each device 
usually has its peculiarities which must be dealt with by the programmer. An in-depth 
understanding of each CRU “Line” in the interface or the operation of the TILINE* is 
necessary before attempting to write code to control the device. A description of a 
device interface may be found in a hardware reference manual for the device. 

2) Interrupt handling on 990 Family of Computers — The programmer should understand 
how interrupts are handled on the 990. 

3) Basic data structures, program structures, and coding techniques used in writing device 
service routines. 


* TILINE is a registered trademark of Texas Instruments Incorporated. 
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In order to support a nonstandard device, the user must generate three separate sections of code: 
A physical device table, an interrupt handler routine, and. a device service routine (DSR). The 
physical device table is created by the system generation program, but the user interactively 
supplies the generation program with the nonstandard information. The user codes the DSR and 
the interrupt handler, which are typically contained in the same module, but may be separate 
modules. 

4.2.1 PHYSICAL DEVICE TABLE. Each device in the system that can be accessed by a LUNO 
has a physical device table (PDT) associated with it. The PDT contains information used by the 
operating system to support the device. The PDT for a new device is created by the system 
generation program (GENTX), with the user interactively specifying the new device as a special 
device (SD). After the standard device requests, CRU base address, access mode, interrupt level, 
and time-out count, the following inputs are requested by GENTX: 

1) CRU interrupt line - The CRU bit displacement from the CRU base address for the 
bit that is “set” when a device interrupt occurs. 

2) Entry label of DSR — The label of the first word of the DSR. An I/O request initiated by 
a supervisor call is entered two words beyond the label. 

3) Entry label of interrupt routine - The label at the entry point to the interrupt routine. 
The interrupt routine is entered at this point when an interrupt occurs. The interrupt 
routine processes the interrupt, usually by branching to the appropriate point in the DSR. 

• 4) Interrupt branch label - The initial address of the routine within the DSR to which 

the interrupt routine branches. Tire address is placed in register 6 of the DSR work- 

space when the operating system is initially loaded. The initial label usually points to 
the routine that handles interrupts when the device is idle. 

5) Extension data - Assembler source code that is placed in the extension field of the 

PDT. This information is totally device dependent, and the field may be empty when 

the new DSR does not require any extra data or temporary storage words. 

4.2.2 INTERRUPT ROUTINE. Wlien a device is interrupt driven, an interrupt routine must be 
supplied by the user. The functions of this routine are to reset the time-out count (for keyboard 
>vices), reset the device interrupt, and transfer control to the appropriate point within the DSR. 

r) le interrupt routine is entered with the DSR workspace of the PDT as the workspace (see 
.igure4-l). The interrupt routine should perform the following functions: 

1) Reset the device time-out count - When the DSR is waiting for an interrupt, the 
operating system decrements the device time-out count each system-time interval. 
When the time-out count is depleted before an interrupt occurs, the current I/O 
operation is aborted. The interrupt routine for keyboard devices must reset the 
time-out count to its original value. Both the original time-out count and the running 
count are contained in the device information block of the PDT (figure 4-1). 

2) Reset the device interrupt - Tliis function depends on the particular device. 

3) Branch to the interrupt entry point - By convention, register 6 of the workspace con- 
tains a pointer to the DSR routine to be entered. 
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NOTE 2 

DEVICE CHARACTERISTICS 
BIT 0 = FILE ORIENTED DEVICE 

1 = TILINE 

2 = TIMEOUT DEVICE 

3 = PRIVILEGED 

4 = CONSOLE 

5 ^ COMMUNICATION DEVICE 

6 -= DEVICE =911 
7-11 - NOT USED 

12-15 = DEVICE TYPE 


Figure 44. PDT Structure 


4-3 


Digits! Systems Division 





944776-9701 



The following is an example of an interrupt routine: 


INTRPT , MOV @4(R4),@6(R4) Reset device time-out count 
■ Code to reset device interrupt 


B *R6 Branch to interrupt entry point 

Register 4 points to the device information block and bytes 4-5 and 6-7 in the device 
information block contain the fixed time-out count and decrementing time-out count. 

4,2.3 DEVICE SERVICE ROUTINE. The device service routine (DSR) consists of several parts, 
including code to perform the initialization required when the power is applied, and the code to 
process an abort or time-out operation. The section of the DSR entered through the entry point 
processes I/O supervisor calls for the device. When the DSR is interrupt driven, there must be an 
interrupt routine to process interrupts. Usually, DSRs are written reentrantly so that they may 

be used by all devices of the same type in the system. In this case, the data area is the PDT and 
the procedure is the DSR. 

The first word of the DSR must contain the address of the entry to the routine that performs 
the initialization when the power is applied. The second word must contain the address of the 
entry to the routine that performs abort or time-out functions. The third word is the first word 

of the portion of the DSR that processes I/O calls. The following is an example of the source 
code for a DSR: 

Address of initialization routine 
Address of abort/time-out routine 
First word of I/O call processor 


1 ) Power-Up/Restart 

2) Abort/Time-Out 

3) I/O Call Handler 

4) Unsolicited Interrupt Handler 

5) Interrupt Handler 

6) Exit Routine 

Figure 4-2 is an example of the typical structure of the DSR. 


DSR DATA PWRUP 

DATA ABORT 
START 

The DSR consists of the following routines: 
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IDT 'GUBDSR' 

DEF GLUBER, GLBNCH , GLBINT 
REF ENDRCD , SETWPS , B2YCHK 
^ ALSO NEED TO REF ANY OTHER SYSTEM ROUTINE LABELS ^ 
GLUBER DATA GLBPWR POWER UP ENTRY 

DATA GLBABT ABORT/TIME-OUT ENTRY 

^ ENTRY HERE FOR I/O SVC S 

LIMI 0 MASK INTERRUPTS 

o 


BL @SETWPS SYSTEM ROUTINE 

(I/O CALL HANDLER) 

B @ENDRCD RETURN TO I/O SUPERVISOR 

UNSOLICITED INTERRUPT HANDLER 
GLBNCH EQU ^ 


RTWP 

^ COMMON INTERRUPT HANDLER 
GLBINT EQU $ 

(RESET THE INTERRUPT) 

B * 6 GO TO BRANCH LABEL 

^ POWER UP/RESTART ENTRY 

GLBPWR EQU $ 

RTWP 

^ ABORT / TIME-OUT ENTRY 
GLBABT EQU $ 


B @ENDRCD 
END 

(A)1 36882 


Figure 4-2. Typical Program Structure of DSR 


4.2.3. 1 Power-Up/Restart Routine. When the operating system is loaded or restarted, either 
manually or through the power-up interrupt, each DSR in the system is entered at its power-up 
entry point. This routine should perforin the following functions: 

1) Reset the interface. 

2) Enable device interrupts if the device is interrupt driven. 

3) Perform any initializations required by the particular device. 


Change 1 
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4) Abort in progress I/O — Check to see if I/O is in progress. This can be done with the 


following instructions: 



MOV 

R1,R7 

Move SCB address +2 to REG 7 

BL 

©BZYCHK 

System routine to check if PDT busy 

JMP 

NOTBSY 

Not busy return 

LI 

R6, EXIT 

Busy, set up exit 

RTWP 


Return 

NOTBSY LI 

R6, SPRINT 

Set up vector for spurious interrupt 

RTWP 


Return 

If the device was busy, the 

error flag and error code (Error Code 4) in the SCB are set 


by BZYCHK. The DSR should then set up a branch to the normal exit point, which 
calls the end record processor. When the next interrupt occurs, the interrupt routine 
branches to the exit routine of the DSR. If the PDT is not busy, the interrupt branch 
vector should be set to the unsolicited internapt routine of the DSR. The “RTWP” 
returns control to the operating system. 

4.2.5.2 Abort/Time-Out Routine. The operating system enters the DSR at the abort/time-out 
entry point in response to an abort I/O call or when a device time-out occurs. This routine must 
perform the following functions: 

1) Set error code in PRB — The routine should call the system routine BZYCHK to verify 
that the PDT is busy. If the PDT is not busy, no more processing is necessary. If the 
PDT is busy, the , error code in the SCB should be set to 6. The error flag has already 
been set by BZYCHK. 

2) Reset the interface — Perform the operations needed to abort the current device I/O. 

3) Other clean up — Perform any functions necessary to clean up any flags or temporary 
information in the PDT. 

4) Branch to exit routine. 

4.2.3.3 I/O Call Handler. The I/O Call Handler is the main part of the DSR. The I/O Call 
^ Handler performs the following functions: 

1) Decode I/O Opcode — The DSR must decode the opcode in the SCB, determine the 
I/O operation requested, and transfer control to the appropriate opcode processor. 

2) Perform the I/O operation — The processor initiates the desired operation and loads 
register 6 with the interrupt branch label. When the next interrupt occurs, the interrupt 
routine branches to the address in register 6. If the processor is waiting for an interrupt 
to signal the operation complete, the DSR is exited with a “RTWP” returning directly 
to the operating system. If the operation is completed, the processor must exit the 
DSR through the exit routine. 

4.2.3.4 Unsolicited Interrupt Handler. The unsolicited interrupt routine handles interrupts that 
occur unexpectedly. When the system is initially loaded or the device is idle, register 6, which 
contains the interrupt branch address, points to this routine. The DSR should set register 6 to 
point to this routine whenever an operation terminates. This routine should determine the reason 
for the interrupt and act accordingly. 
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4. 2. 3. 5 Exit Routine. The Exit Routine should perfomi the final cleanup of the PDT and/or 
interface before the DSR exits to the end-record routine via a B @ENDRCD instruction. The inter- 
rupt branch vector, register 6, Should be set to the unsolicited interrupt routine. The end-record 
routine closes the device (if record oriented) by clearing the TSB in the PDT, clears the busy flag in 
SCB and PDT, and reactivates the task (if suspended on I/O). 

% 

4.2.5.6 Programming Techniques. When handling I/O calls, the DSR frequently executes a CRU 
operation and then waits for notification that the operation is complete. If this notification is an 
interrupt, then the DSR may use the following strategy: 

LI R6,ADDR Set up entry address 

RTWP Return 

Wlien the interrupt occurs, control will be passed to ‘ADDR’ in the DSR after the interrupt line 
has been reset by the interrupt routine. 

In some cases, it is necessary to await the occurrence of an event which generates no interrupt. 
Therefore, the DSR must poll for the event. The user may set the DSR timer reentry flag (bit 5 
in R2 of PDT) so that the DSR will be entered at the next system-time interval to test for the 
event. The code to accomplish this is as follows: 

LI R6,ADDR Set reentry address 

ORI R2,>0400 Set timer reentry flag 

RTWP Return 

When the DSR is reentered because of the timer, the system resets the flag. If the desired event 
has not occurred, the flag must be set again by the DSR. If an interrupt occurs, the interrupt 
routine branches to ‘ADDR’. 

4.3 EXTENDED OPERATION ROUTINES 

When an extended operation is required, the user must w-rite a routine to perform the required 
processing. The user supplies the extended operation number (level), the entry point, and the 
workspace address at system generation time. The system places the entry point and the 
workspace address in the memory locations corresponding to the extended operation level. When 
a user task executes an XOP command with that level number as the operand, the computer 
places the effective address of the command in workspace register 1 1 of the XOP routine 
workspace, and performs a context switch to the XOP routine. That is, the XOP routine 
workspace becomes the active workspace, XOP (the entry point) is placed in the PC, the 
previous contents of the WP register are placed in workspace register 13, the previous contents of 
the PC are placed in workspace register 14, and the previous contents of the ST register are 
placed in workspace register 15. 

The XOP routine may retrieve parameters from the calling program by indirect addressing 
through register 11 or by using indexed addressing with register 11. For example: 

MOV *11,7 Move parameter pointed at by register 11 to 

register 7. 

MOV @2(1 1),7 Move parameter which is 1 word (2 bytes) past 

the word pointed at by register 1 1 to 
register 7. 


4-7 


Digital Systems Division 



944776-9701 


The TX990 operating system provides three entry points for returning control to the system 
from an extended operation routine. When a routine returns control to XOPRTl, the calling task 
continues execution immediately. When a routine returns control to XOPRT2, the calling task is 
suspended. When a routine returns control to XOPRT3, the current time slice of the calling task 
is terminated, arid the task is placed at the end of the active list, just as if it had completed the 
time slice. The extended operation routine must return control at one of these points, as 
appropriate. The following examples show these returns: 

B ©XOPRTl Return and continue execution of calling task. 

B ©XOPRT2 Return and suspend calling task. 

B ©XOPRT3 Return, terminating current time slice of 

calling task. 

An extended operation routine must externally define (DEF directive) the workspace address and 
the entry address. It must also externally reference XOPRTl, XOPRT2, or XOPRT3, whichever 
return point is used by the routine. More than one of these return points may be used, but each 
must be referenced. 

An extended operation may use the workspace without any restriction except that if the 
contents of workspace registers 13, 14 and 15 are altered, they must be restored before returning 
control to the system. 

4.4 USER-SUPPLIED SUPERVISOR CALL ROUTINES 

When a supervisor call (XOP 1 5) that is not provided by the system is required, the user must 
write a routine to perform the required processing. The user specifies the call code for the 
supervisor call and the entry point during execution of GENTX. The user-defined supervisor call 
codes begin at SOig. Codes 0 througlr 7Fi6 are reserved for system-defined supervisor calls. The 
system places the entry point in a table from which it is accessed when the call code is 
recognized in a supervisor call. The system transfers control to the user’s routine with the 
following instruction: 


B *R6 R6 contains the entry point of the user’s 

routine. 

A system workspace having the contents shown in figure 4-3 is the active workspace when the 
supervisor call routine is entered. The user’s routine may destroy the contents of any workspace 
register except workspace registers 13, 14 and 15. If the user’s routine alters the contents of 
workspace register 13, 14 or 15, the routine must store the contents of the register and restore 
the contents before returning control to the system. Register 8 contains the address of the Task 
Status Block (TSB) of the task issuing the supervisor call. 

Return to the system utilizes the same entry points defined for extended operation routines, and 
the same three options apply. The supervisor call routine must branch to XOPRTl, XOPRT2, or 
XOPRT3, as previously described. 

The user must externally define (DEF directive) the entry point and externally reference (REF 
directive) the return point or points used in the routine. 


4.5 OPERATOR COMMAND PROCESSING 

Processing of operator commands is performed by five or more modules of the Operator Communi- 
cation Package (OCP). The OCP consists of four required modules and from one to five optional 
command processor modules. The user may modify the OCP commands, add one or more command 
processors to a command processor module, or add one or more command processor modules to 
OCP. 


Change 1 
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Figure 4-3. Workspace Contents for Supervisor Call Routine 

Table 4-1 lists the OCP modules supplied by Texas Instruments. OCP executes as a system task, 
consisting of a data division (OCPTSK) and a procedure division (OCPPRC). Module OCPTBL 
contains tables of data that support the command processors that execute as subroutines of the 
procedure division. Module OCPEND contains external definitions to satisfy external references 
to the optional modules. It contains a dummy command word table to process optional' 
commands that have been omitted and external definitions to satisfy references to error messages 
in optional modules. OCPEND must always be linked following the other OCP modules. 

Figure 4-4 shows the flow of the processing of OCP commands. After the command line is 
entered, the pre-scan logic of the OCPPRC module removes embedded blanks and inserts commas 
for separators where blanks were used. When the last con'imand in the command line has been 
processed, control returns to the logic that enters a new command line. Otherwise, OCP decodes 
the command, branching to print an error message when the command code is not in the 
command tables. Decoding the command results in passing control to the appropriate command 
processor. After performing the command processing, the command processor returns control to 
the OCPPRC module; those commands that perform repetitive I/O reenter the command processor. 
Others return control to test for additional commands in the command line. 
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Table 4-1. OCP Modules 

Name 

Description 

OCPTSK 

OCP Data Division 

OCPTBL 

OCP Tables 


Linking Order 

First 

Second 



OCPPRC 

OCPLRT 

DOCPLRT 

OCPSLD 

OCPIOU 

DOCPIOU 

OCPTAD 


OCP Procedure Division 

Command Processors for ALUNO, RLUNO 
LPROG, and EXECUTE commands. 

Command Processors for ALUNO, RLUNO, 
LPROG, EXECUTE, ITASK, IPROC, DTASK, 
and DPROC commands. (Replaces OCPLRT in 
multiple dynamic task system.) 

Command Processors for LMEM, DMEM, SBKPT, 
CBKPT, ADD, SUB, and JMP commands. 

Command Processors for ST ASK, SIO, REWIND 
FSPACE, and BSP ACE commands. 

Command Processors for ST ASK. SIO, REWIND 
FSPACE, BSPACE, and SPROC commands. 
(Replaces OCPIOU in multiple dynamic task 
system.) 

Command Processors for TIME and IDATE 
commands. 


Third 

Between OCPPRC 
and OCPEND 

Between OCPPRC 
and OCPEND 


Between OCPPRC 
and OCPEND 

Between OCPPRC 
and OCPEND 

Between OCPPRC 
and OCPEND. 


Between OCPPRC 
and OCPEND 


Command Processors for DWKSP, KIO, and 
KTASK commands. 

Dummy external definition module. 

Decoding of a command involves a table in the OCPTBL module and tables in the applicable 
command processor module. Each command processor module contains a Command Word Table 
having a two-word entry for each command processor in the module, and a terminator. The first 
word of the entry contains the two-character command code; the second word contains the 
entry point of the command processor for the command. The OCPTBL module contains a 
Command Word Table Address Table, consisting of the addresses of the Command Word Tables 
in each of the command processor modules linked to OCP. 


Between OCPPRC 
and OCPEND 

Last 


OCPTLD 


OCPEND 


Upon entry to a command processor, workspace registers 1,6, 10, and 15 contain the following 
information: 


• Register 1 contains the two-character command code. 


® Register 6 contains the address of module OCPTSK. 


Change 1 
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• Register 10 contains the address of the separator (either a comma or a period) at the 
end of the command word. If the command has one or more operands, the first 
operand begins at the next address. 


• Register 1 5 contains the address of subroutine GETHEX. (Described in a subsequent 
paragraph.) 


Change 1 
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If a command processor alters the contents of register 6, it must restore the contents before 
exiting. Tire command processor may use register 10 to obtain the operand of the command (or 
for any other purpose), but must place the address of any character within the command in 
register 10 before exiting. That is, register 10 may contain the address of the first character of 
the command, word or the period that terminates the command, or any character between these 
characters. The command processor may use the other registers with no restrictions. 


OCPPRC contains two subroutines that a command processor may call to obtain an operand. 
Subroutine GETARG is useful for obtaining decimal operands or those that contain characters, 
and subroutine GETHEX may be used to obtain hexadecimal operands. 


Subroutine GETARG obtains the operand that starts in the byte following the byte addressed by 
register 10 and ends at a separator. GETARG places the operand riglit-justified in a six-byte 
string at location ARGBF2. The string is blank filled to the left. The word preceding the six-byte 
string may be used to build a supervisor call block for converting a decimal operand to binary. 
The location of the word preceding the string is ARGBUF. The calling sequence for subroutine 
GETARG is as follows: 


BL 

©GETARG 

JMP 

PERIOD 

JMP 

ERROR 


Branch to subroutine GETARG. Control 
returns to the word following the BE instruction 
when th^ operand contains only a period. When 
the operand contains more than six characters, 
control returns to the second word following 
the BL instruction. When the GETARG opera- 
tion is successful, control returns to the third 
word following the BL instruction. 


Upon return from subroutine GETARG, register 10 contains the address of the separator that 
follows the operand in the six-byte string at location ARGBF2. 


Subroutine GETHEX obtains the hexadecimal operand that starts in the byte following the byte 
addressed by register 10 and ends at a separator. GETHEX converts the characters to a binary 
number and places the result in workspace register RO. The calling sequence for subroutine 


GETHEX is as follows: 


BL 

©GETHEX 

JMP 

PERIOD 

JMP 

ERROR 


Branch to subroutine GETHEX. Control 
returns to the word following the BL instruction 
when the operand contains only a period. When 
the operand contains an invalid hexadecimal 
digit, control returns to the second word fol- 
lowing the BL instruction. Otherwise, control 
returns to the third word following the BL 
instruction. 


If the OCP command processor has not altered register 15, a BL *15 instruction may be used to call 
GETHEX. 

Upon return from subroutine GETHEX, register 10 contains the address of the separator that 
follows the operand returned in register 0. 

Return from a command processor is to a return point in OCPPRC. One return point terminates 
the command with no output, three return points terminate the command with printed messages 
and another return point provides a specified I/O operation to a specified LUNO. 
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A return to location SCANPD passes control to OCPPRC for processing the next command with 
no output. This return is appropriate for commands that require no messages or results to be 
printed. 

A return to location OCPRTN causes OCPPRC to print a message from buffer OUTBUF on 
LUNO 0 or LUNO 1 with optional additional processing. The option is specified by the termi- 
nating character placed in the buffer following the last character to be printed. The characters 
and the LUNOs and options are as follows: 

• FCi 6 — print on LUNO 0, omit processing of any additional command on current 

command line. 

3 ® FDjg — print on LUNO 0, process next command. 

~Z ® FEi 6 — print on LUNO 1, reenter command processor. 

— 'I • FFi 6 — print on LUNO 1, process next command. 

The first option, using terminator FCi6, is appropriate for an error condition because the 
remaining commands of the command line, if any, are skipped. The third option, using 
terminator FEi^, is appropriate for a repetitive command, such as a dump command. The other 
options return control to the next command. 

When the FEi^ terminator is used and the command processor is reentered following the 
printing of the message, the user must place an address in workspace register 3 before returning 
to location OCPRTN. Workspace register 3 must contain the address in the command processor 
at which it is reentered. OCPPRC alters the contents of registers 0, 1, and 2. The restrictions on 
the use of registers 6 and 10, described previously, apply. Otherwise the command processor may 
use the workspace registers as required. 

A return to location ERRMSG causes OCPPRC to print an error message on LUNO 0. The error 
message is specified by an error code in workspace register 0. Control passes to the first 
command on the next command line, omitting any additional commands on the current line. 
T^e text of the error message may ’be in the command processor or in module OCPTBL. Table 
ERRTBL in module OCl’TBL lists the error codes and the addresses of the associated error 
message texts. 

A return to location ARGERR causes OCPPRC to print an error message on LUNO 0. The error 
message is as follows: 

OPERAND ERROR(S) 

Control passes to the first command on the next command line, omitting any additional 
commands on the current line. 

A return to location lOURTN causes OCP to perform an I/O operation on a specified device and 
to process the next command. Workspace registers 8 and 13 define the operation and specify the 
device. The I/O operation code is placed in the most significant byte of register 8, and the 
LUNO is placed in the least significant byte. For forward or backward space operations, the 
number of records is placed in register 13; For other operations, the contents of register 13 are 
not significant. Since tlie interface with subroutine lOURTN has no provision for specifying a 
buffer, I/O operations that require a buffer (read or write, for example) are not valid. lOURTN 
performs an Open operation, the specified operation, and a Close operation, then processes the 
next command. 
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4.5.1 MODIFYING AN OCP COM.MAND. To modify an OCP command, the user should obtain 
the source listing of the OCP modules from Texas Instruments, and modify the command 
processor to perform the operation in the desired manner. The subroutines and return locations 
in OCPPRC described in the preceding paragraph may be used as required. 

4.5.2 ADDING AN OCP COMMAND TO A MODULE. The command processor for an OCP 
command must be a serially reentrant routine. As described previously, fourteen workspace 
registers of the workspace are available for temporary storage of data. When more space is 
needed, it must be provided in module OCPTSK by adding directives to provide the space at the 
end of the module. When the command processor detects an error for which one of the existing 
error messages is appropriate, the user may call subroutine ERRMSG with the error code for that 
message in RO. When the error requires a message unique to the command, the user should 
include the text of the message in the command processor, and list the error code and the 
address of the text in table ERRTBL in module OCPTBL. When an error requires an additional 
message common to several command processors, the text of the message should be placed in 
OCPTBL, and the error code and text address placed in table ERRTBL. Any exit from the 

^ command processor must be to one of the return points in OCPPRC. 

A two-word entry for the new command must be added to the Command Word Table of the 
command processor module. The zero that terminates the Command Word Table must be placed 
following the additional entry. 

4.5.3 ADDING AN OCP COMMAND MODULE. An OCP command module may contain one or 
more additional command processors, each of which must meet the requirements outlined in the 
preceding paragraph. The module must contain a Command Word Table consisting of a two-word 
entry for each command processor, terminated with a word that contains zero. The address of 
the Command Word Table in the added module must be placed in the Command Word Address 
Table in OCPTBL. The symbolic address of the Command Word Table in the added module must 
be added to the dummy word structure in OCPEND. 
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SECTION V 
DATA STRUCTURES 


5.1 GENERAL 

Tliis section describes the internal data structures of the TX990 operating system, including 
internal tables and file structures. 

5.2 TXDATA 

TXDATA contains most of the system data structures that change according to the specific 
system configuration (TASKDF contains the other data structures that vary.) TXDATA is generated 
in source statement form by the system generation program. The module must be assembled before 
being linked with the system. The first two words of TXDATA contain a branch instruction to 
the restart routine of the operating system. TXDATA should be the first module in the link to 
provide for ease in restarting the system. 

5.2.1 DEVICE NAME TABLE. The device name table (DNT), generated at system generation 
time, is used by the system to map device names to devices. Each device included in the system 
has an entry in the DNT. Each entry, as shown in figure 5-1, consists of a pointer to the device 
PDT and a four character device name. The name is left justified in the field with trailing spaces. 
The dummy device has a zero value for the PDT address. The position of the entry in the table 
determines the internal unit number of the device. 

5.2.2 LOGICAL DEVICE TABLE. Each LUNO assigned has a logical device table (LDT) 
associated with it. The LDT provides the link between the LUNO and the physical device or 
disc file. The LDT is built either by the system generation program when a LUNO is 
specified or by the file utility routine (FUR) when an assign LUNO supervisor call is made. 
When a LUNO is assigned, a buffer is allocated from the buffer pool for this LDT. There are two 
kinds of LDTs: device and file. A device LDT, shown in figure 5-2, maps a LUNO to a device; 
and a file LDT, shown in figure 5-3, maps a LUNO to a particular file on a disc. 
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Figure 5-1. Device Name Table (DNT) Entry 
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■ Figure 5-3. File LOT 


5.2.2. 1 Device LDT. Bytes 0-1 contain the address of the PDT for the device to which the 
LUNO is assigned. 

Byte 2 contains the actual LUNO. 

Byte 3 contains the device number (positional entry in the DNT). 

Byte 5 contains flags. Bit 0, when set, indicates that the LLTNO is a system LUNO and may 
not be released or reassigned. Bit 1 will be a zero to indicate a device LDT. All other bits are 
ignored. 

Bytes 6-7 contain a link to the next LDT in the chain. 

.5 .2.2.2 File LDT. When the file is opened, bytes 0-1 contain the FCB address of the file in 
memory. When the file is not open, this field is zero. When the file is in the process of being 
opened, this field is a negative one. 

Byte 2 contains the actual logical unit number (LUNO). 

Byte 3 contains the disc device number (positional entry in the DNT). 

Byte 4 contains the LUNO assigned to the disc drive on which the file is resident. 
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Byte 5 contains flags. Bit 0, when set, indicates that the LUNO is a system LUNO and 
cannot be released or reassigned. Bit 1 will be set to one to indicate that this is a file LDT. 
Bit 2 is set to one by file management in the open processor when the file is write 
protected. Bit 3 is set to one by file management in the open processor when the file may 
be shared with other tasks. Bit 4 is the rebid flag and, when set, indicates that the task 
should be rebid when file management finishes processing the current I/O call. Bit 5 is set 
by FUR in the assign LUNO operation to indicate that the file should be created at open 
time if it does not exist. Bit 6 indicates that volume names are being used. 

Byte 6-7 contain the link to the next LDT in the chain. 

Bytes 8-9 contain the file type. A zero indicates a sequential file and a two indicates a 
relative record file. 

Bytes 10-1 1 contain the SCB address ■^2 of the current I/O call. This field is zero when no 
calls are pending or being processed for this LUNO. 

Bytes 12-13 contain the TSB address of the task issuing the I/O call. 

Bytes 14-15 contain the logical record length of the relative record file. This field is used 
only when a relative record file is auto-created at open time. This field is zero for a 
sequential file. 

Bytes 16-19 contain the diskette or volume name. 

Bytes 20-26 contain the seven character file name. The name is left justified in the field and 
blank filled. 

Bytes 27-29 contain the three character extension name. The name is left justified in the 
field and blank filled. 

5.2.3 BUFFER POOL. TX990 maintains a pool of internal buffers wliich are dynamically 
allocated and deallocated by buffer management for use as logical device tables, file blocking 
buffers, intertask communications messages, etc. The size and number of these buffers are specified 
at system generation time. A separate list is maintained for buffers of each size. A header table 
contains an entry for each buffer size that points to the beginning of the respective list. Figure 5-4 
shows the structure of the header table and figure 5-5 shows the linkage between buffers. 
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Figure 5-5. Buffer Linkage 

5.2.3. 1 Header Table. For each size of buffer, there is a two word entry in the header table. 
Word 1 points to the buffer at the top of the list and the second word is the buffer size. BUFH 

' is the label of the first entry and BUFF is the label on the last entry in the table. BUFF is the 
label of the entry associated with the buffer created during SYSGEN as a “default buffer”. A 
call to buffer management for a fixed length buffer allocates a buffer from this list. The 
communication package uses this buffer size. 

5.2. 3.2 Buffer Linkage. Preceding each buffer is a data word containing the size of the buffer. 
This word is used to determine wlfich list the buffer belongs on when the buffer is deallocated. 
The first word of the buffer is the link to the next buffer and points to the word preceding that 
buffer. The last buffer in the chain has a zero link. 

5.2.4 FMPBUF. When a disc is included in the system at system generation time, the system 
generation program generates a buffer called FMPBUF. This buffer is used by file management 
and the file utility routine as a temporary blocking buffer for use with create, compress, delete, 
etc. The use of FMPBUF is restricted by the flag FMPFLG. FMPBUF is 224 bytes in length for 
the diskette system. 

5.2.5 PHYSICAL DEVICE TABLES. Each device in the system that can be accessed by a 
LUNO has a physical device table (PDT) associated with it. The PDT contains information used 

/•K by the operating system to support the device. All PDTs are chained together with the address of 
the first PDT in the chain contained in the word PDTSTR. The system table contains this pointer. 
No words initialized by the system generation program can be modified by the DSR unless other- 
wise stated. The size and contents of the PDT vary according to the particular device. 

The PDT consists of three parts: device service routine (DSR) workspace, device information 
block, and DSR temporary storage. The DSR workspace and device information block are of 
fixed size; the DSR temporary storage area is variable and dependent on the device. 
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5.2.5. 1 DSR Workspace. The first 16 words of the PDT (see figure 4-1) are used as the workspace 
for the DSR when an I/O call is used. Some of the registers are used as scratch registers by tlie DSR 
and some contain device-related information used by both the DSR and the operating system. The 
registers are as follows: 

• Register 0 — Used by the system to link PDTs. Register 0 may not be modified by the 
DSR. 

• Register 1 — Contains the address of the second word of the supervisor call block (SCB). 
The operating system places this value in register 1 prior to entering the DSR. 

• Register 2 — Device status word. Contains information about the current status of the 
device. Bit 2, the initiate I/O flag, is set by the operating system in response to an 
initiate I/O call and cleared when the operation is completed. Bit 4 is the close device 
flag. If set by the operating system, it causes the device to be deassigned when the 
operation terminates. This bit is always set for a record-oriented device. For file- 
oriented devices, this bit is set for close and abort operations only. Bit 5, the reentry 
flag, is set by the DSR to cause the DSR to be reentered at its intemipt entry point 
when the current system time interval expires. Bit 7 is used by communication devices 
to differentiate between abort LUNO and abort SCB supervisor calls. Bits 12-15 
contain the interrupt level, minus one, of the device. 

® Register 3 — The device characteristics word. Contains static information about the 

device. This word is generated at system generation time and should not be altered 
during execution. Bit 0, when set, specifies that the device is file oriented. Bit 1 , when 
set, designates the device as a TILINE device rather than CRU device. When bit 2 is 
set, the system will time-out I/O operations to a device. Bit 3, when set, specifies that 
a task must be privileged to access the device. Bit 4 designates this device as the system 
console. Bit 5 specifies that this device is a communication device and that special 
handling is required. Bit 6, when set, indicates that the device is a 911 VDT rather 
than a 913 VDT. Bits 12-15 contain the device type code. 

• Register 4 — contains the address of the device information block. This address is 
generated by the system generation program and sliould not be modified. 

• Register 5 - Contains the keyboard status block (KSB) address when the device is a 

VDT or contains the address of the multiunit workspace for a device witli multiple 

units per controller. When neither of these conditions apply, this is a scratch register 
for DSR usage only. The KSB or multiunit workspace address is supplied by the 
system generation program. 

o Register 6 - Normally contains the internal DSR reentry branch address used by the 
interrupt routine to branch within the DSR. It may also be used as a scratch register. 

® Registers 7-11 — DSR scratch registers. 

® Register 12 — Contains the CRU base address or TILINE address of the device 
supplied by the system generation program. 

• Registers 13-15 — Contain the return vectors. 
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S.2.5.2 Device Information Block. The device information block (figure 5-6) contains information 
supplied and used by the operating system and DSR to control the device I/O. The block is a fixed 
length for all PDTs, with the following entries: 


Bytes 0-1 — Contain the TSB address of the task to which the device has been allocated. 
The device is not allocated when this field is zero. 

Bytes 2-3 — Contain the address, supplied by the system generation program, of the DSR. 

Bytes 4-5 — Contain the timeout count specified at system generation time. 

Bytes 6-7 — Contain the number of system-time intervals remaining before the device will 
timeout. This field is initialized to the timeout count in bytes 4-5 before the DSR is called 
by the operating system. 

Bytes 8-9 — Contain the interrupt entry point into the DSR. This field is supplied by the 
system generation program. 

Bytes rO-13 — Contain the first and last entry pointers of the PDT queue. The entries in 
the PDT queue are the TSBs of the tasks requesting the services of the DSR. This queue is 
used by the operating system to control access to the DSR. 

Bytes 14-15 — Contain the address of the LDT currently being processed by the DSR. This 
field is zero when the DSR has finished processing all I/O calls. 

Bytes 16-17 — The busy flag. Set to FFFF when the DSR is processing an I/O call. 

Bytes 18-21 — Contain the workspace and status of the operating system prior to the 
“BLWP” to the DSR. These values are saved to ensure no loss of‘ content if an interrupt 
occurs while the DSR has interrupts enabled. 

5.2.5. 3 DSR Temporary Storage. This block contains information that is used by the DSR only. 
Tire size of the block varies according to the device. The system generation program has an 
internal table used to generate the block along with the initial values. The user must supply this 
block for nonstandard devices. Some devices (i.e., line printer and card reader) do not require 
any temporary storage. 

g 5.2.6 MULTIUNIT WORKSPACE. Some DSRs support more than one device (i.e., disc per con- 
I troller). These DSRs require, in addition to one PDT per device, a single workspace to identify 
the device causing the interrupt (see figure 5-7). The multiunit workspace is created by the 
system generation program for any standard devices requiring this workspace. When an interrupt 
occurs, the DSR interrupt decoder is entered and this workspace is used. 

Registers 0— (N-1), where N is the number of devices per controller, are the PDT addresses of each 
device supported by the controller. (For a diskette controller, there are a maximum of four PDT 
addresses.) 

Register 12 is the CRU or TILINE address of the device. Tliis address is supplied by the system 
generation program. 

Registers 13-15 contain the workspace, PC, and status of the program interrupted. 

All other registers are. scratch registers for decoder usage. 
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5.2.7 KEYBOARD STATUS BLOCK. Each VDT in the system requires a keyboard status block 
(KSB) for the workspace of the keyboard interrupt as shown in figure 5-8. The KSB, in addition 
to being a workspace for the interrupt handler, contains a queue of the characters input from, 
the keyboard. If the mode flag, register 0, contains a nonzero value, the VDT is^^ allocated to 
a task. The mode flag is the TSB address of the task if the VDT is allocated. 

® Register 1 points to the beginning of the character queue. 

« Register 2, the input pointer, points to the location within the character queue at 
which to store the next character entered. 

® Register 3, the output pointer, points to the next character to be retrieved by either 
the DSR, Get Character Supervisor call, or VDT utility. 

® Registers 4-6 are the character queue. 

• Register 7, byte 0, is used by the 91 1 VDT as a constant, C0,6, and marks the end of 

the character queue. For the 913 VDT, this byte is the last character in the queue. 

Register 7, byte 1 , contains flags used by the interrupt handler and DSR. Bit 0 must 

be a 1 to indicate the end of the character queue, although it is not needed for the 

911 VDT. Bit 1, when set, indicates that the device may be halted (by entering the 
space key) or aborted (by entering the escape or reset key). This bit is set by the DSR 
when displaying data. Bit 2, when set, directs the DSR to halt the display of any nev/ 
characters. Bit 3, when set, directs the DSR to abort the current display operation. Bits 
4, 5, and 6 are not used, and are set to zeros. Bit 7 is set by the system generation pro-' 
gram to indicate a 91 1 VDT. 

• Registers 8-1 1 are scratch registers for station handler usage only. 

• Register 12 contains the VDT CRU address + 10,6 . This field is generated during system 
generation. 

® Registers 13-15 contain the content of the interrupted task (i.e., WP, PC, and ST). 

A list of the KSBs in the system in maintained in the KSB table. The table consists of the KSB 
addresses listed sequentially according to station number. The table is terminated with a zero 
entry. 

5.2.8 INTERRUPT VECTOR TABLE. For each interrupt defined at system generation time, an 
interrupt vector is created. Each entry in the interrupt vector table, shown in figure 5-9, contains 
the hardware trap vector address and the PC and WP to be placed at that address. The hardware- 
trap vector address is the actual memory address from which the hardware interrupt logic 
retrieves the interrupt branch vectors. The PC points to the entry point in the interrupt decoder 
for this interrupt (described below). These vectors are placed in the hardware interrupt trap 
locations when the system is initially loaded. The interrupt vector table does not contain the 
interrupt vectors of the system interrupts, 1 (powerup), 2 (CPU), 5 (clock). These vectors are 
contained in TXEND. The interrupt table is terminated by a negative one in the trap address 
field. 


5-8 


Digital Systems Division 


/ 


BYTE NUMBER 
DEC. HEX 


0 

0 

1^0 

2 

2 


4 

4 

n 

6 

6 

R3 

8 

8 


10 

A 


1 2 

C 

(U 

14 

E 


IG 

10 

n 

18 

1 2 

IS.3 

20 

14 

(1‘10 

22 

16 

(I'll 

24 

18 

to. 

26 

lA 


28 

1C 


30 

IE 



USE 

‘ MODE FLAG 
QUEUE ADDRESS 

INPUT POINTER 
OUTPUT POINTER 
CHARACTER QUEUE 
CHARACTER QUEUE 
CHARACTER QUEUE 
CHAR QUEUE FLAGS 

SCRATCH REGISTER - R8 
SCRATCH REGISTER - R9 
SCRATCH REGISTER - RIO 

SCRATCH REGISTER - Rll 
KEYBOARD CRU BASE 
SAVED WP 
SAVED PC 
SAVED ST 


SYSGEN INITIALIZATION 
0 

DATA $+€ 

DATA $+4 
DATA $+2 
0 
0 
0 

>80 ( 9 T 3 ) 

>C08 1 (9 11) 


CRU BASE 
0 
0 
0 


(A) 136887 


(A)l 36888 


FLAGS 8 - MUST BE A 1 FOR VDT 9 13 
9 - HALT/ABORT ACTIVATED 

10 - HALT- DISPLAY 

11 - ABORT DISPLAY 
15 - VDT 91 1 KSB 


Figure 5-8. TX990 KSB 


TRAP ADDRESS 
WP 
PC 


Figure 5-9. Interrupt Vector Table 


Digital Systems Division 



944776-9701 



5.2.9 INTERRUPT DECODER. For each interrupt defined at system generation time, an 
interrupt decoder is created. The interrupt decoder determines which device caused the interrupt 
when multiple devices exist on the same interrupt level. The decoder contains the workspace 
address and entry point for each of the individual device interrupt routines. After the DSR 
returns to the interrupt decoder, it branches to a common return in the task scheduler 
(TXROOT). Figure 5-10 is an example of an interrupt decoder with interrupts 3 and 6 defined. 
Interrupt 6 has two devices on the interrupt level. 

5.2.10 USER-DEFINED SVC TABLE. When a user-defined supervisor call is defined at system 
generation time, an entry is created for it in the user SVC table. The user SVC table consists of 
a two-byte entry for each supervisor call. Each two-byte entry is the entry address into the 
processor for that supervisor call. The supervisor call code of an entry is relative to the beginning 
of the table. The first entry corresponds to SVC 80,6. The second corresponds to SVC code 
81,6. Space in the table is allocated for SVC code 80,6 to be the largest SVC code defined. The 
entry for any SVC code within the table that has not been defined will be zero. 


5.2.11 ACTIVE QUEUE WEIGHTING FACTORS. GENTX generates a table, shown in 
figure 5-11, which specifies the weighting factor for each of the four priority levels, 0-3. Each 
' entry consists of two bytes. Byte 0 is the number of time slices remaining for this priority level 
before the next lower priority level is given a time slice. Byte 1 contains the number of time 
slices allocated to this priority level. Byte 0 is decremented each time that priority level is given 
a time slice. When byte 0 becomes zero, the next lower priority level is allocated one time slice 
and byte 0 is reset to the value of byte 1 . 


5.2.12 INTERTASK MESSAGE QUEUE. The Put Data supervisor call is used to send messages 
and/or data to other tasks. The message is placed in the Intertask Message Queue and may be 
retrieved by the Get Data supemsor call. (The buffer for the message is obtained from the buffer 
pool. Figure 5-12 shows the format of the message on the queue. 


Bytes 0-1 
Bytes 2-3 
Byte 4 
Byte 5 
Bytes 6-7 
Bytes 8-n 


contain the queueing link. 

contain the size of the buffer allocated for the message, 
is not used. 

contains the message ID. 

contain the number of characters in the message, 
contain the message. 


5.3 TASK DEFINITION 

The system generation program creates a task definition module, TASKDF. TASKDF consists of 
task status blocks linked together. TASKDF is a source module and must be assembled before 
being linked with the system. 
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Figure 5-1 1 . Active Queue Weighting 
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Figure 5-12. Intertask Message Format 

5.3.1 TASK STATUS BLOCK. Each task linked with the system requires a task status block 
(TSB) as shown in figure 5-13. The TSB is used to control the execution of the task. 

Bytes 0-1 - Contain the queuing link, which is used when the TSB is queued. A TSB may 
be queued on the active queue, file management queue, diagnostic queue, device queue, etc. 

Bytes 2-7 — Contain the current WP, PC, and ST of the task. These bytes are updated 
whenever a task’s time slice terminates. The initial values of WP and PC are retrieved from 
the first two words of the task. 

Byte 8 — Contains the priority level, 0-3, of the task. 

Byte 9 - Contains the current state of the task. Possible task states are listed on 
figure 5-13. 

Byte 10 - Contains task status flags. Bit 0, when set, indicates that the task is privileged. 
All tasks linked with the system are privileged. Bit 3 indicates that the task contains an end 
action vector in the third word of the task. When a task error occurs, the system branches 
to the user’s end action routine. If this bit is not set, a fatal task error causes the diagnostic 
task to be called. Bit 6, when set, indicates that the task is being aborted, either from an 
end program or end task supervisor call or from a kill task OCP command. Bit 7, when set, 
indicates that an Unsuspend supervisor call was issued to a task that was not suspended'. 
The next Unconditional Suspend supervisor call is overridden by this set bit and the bit 
cleared. Bits 2, 4, and 5 are not used and are set to zeros. 

Byte 1 1 — Contains the task I.D. 
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Bytes 12-13 — Contain the beginning address of the task. 


Bytes 14-15 - Used for temporary storage. When the task is in a time delay, this word 
contains the number of system-time intervals remaining in the delay. When a fatal task error 
occurs, the task error code is passed via this word to the diagnostic task. The LDT address 
is passed via this word when file management is called. 

Bytes 16-17 — Contain the static link to the next TSB in the chain. This field will be zero in I 
the last TSB in the chain. I 

Byte 18 — Contains the initial task state. Bits 0-3 contain the initial status of the task when 
the operating system is loaded, restarted, or at powerup. Bit 0, when set, indicates the task 
is privileged. Bit 2, when set, indicates the task is to be executed at power restart. Bit 3, 9 

when set, indicates the task is to be executed when the operating system is loaded or at 
restart. Bits 4 through 7 contain the task priority for restart or power up. 

Byte 19 — Contains the ID of the attached procedure. This field is 0 if no procedure is B 
attached. | 

Bytes 20-27 - Used for temporary storage. When a task is queued for I/O, the call is re- 
executed from the TSB. A two-word XOP instruction and a two-word branch to return to 
the task are stored here and then executed. When a task is bid, the task parameters are stored 
in bytes 24-27. A Get Parameters supervisor call retrieves the parameters from this area. 9 

5.4 TXROOT 

The data structures contained in TXROOT are those that are configuration independent (i.e., 
structures that do not vary according to the devices or modules included in the system). Tliese 
structures include queue headers, supervisor call table, and flags. 

5.4.1 SYSTEM TABLE. The system table, shown in figure 5-14, consists of pointers to other 
structures in the system. This table may be accessed by privileged tasks through the get system 
table supervisor call. The system table consists of the following entries: 

Bytes 0-1 - Contain a pointer 4o the time and date block. The time and date block consists 
of Julian year, day, hour, minute, and second in that order. 

Bytes 2-3 - Point to the first TSB in the TSB chain. 

Bytes 4-5 - Point to the first PDT in the PDT chain. 

Bytes 6-7 - Point to the first LDT in the LDT chain. 

Bytes 8-9 — Point to the default disc name. The default disc name is generated by the 

system generation program. 

Bytes 10-11 - Point to the default printer name. The default printer name is generated by 
the system generation program. 

Bytes 12-13 - Point to device name table. The device name table associates a logical name | 
to type device. | 

Bytes 14-1 5 - Point to the first PSB in the PSB chain. I 
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Figure 5-13. Task Status Block 
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DEFAULT PRINTER NAME POINTER 
DNT POINTER 


PSB CHAIN POINTER 


Figure 5-14. System Table 


Change 1 


5-14A/5-14B 


Digital Systems Division 





._r\rn 944776-9701 



5.4.2 SYSTEM FLAGS. TXROOT contains a number of words vised as flags by the system. 
These flags are used to force exclusive access to a resource (routine or buffer) and are set to 
negative one when the operating system is loaded and at system restart to indicate that the 
resource may be accessed. The user executes a test and set (ABS instruction) on the flag to gain 
access to the resource. The flag should be reset by the user to negative one when the resource is 
released. The three flags are FMPFLG, FURFLG, and LDRFLG. FMPFLG controls access to 
FMPBUF. FURFLG controls access to routines in FUR. LDRFLG controls access to the task 
loader routine. 
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5.4.3 QUEUES. The basic structure used by the operating system to control the execution of 
tasks is the queue. The queue is used to force a first-in/first-out (FIFO) order to tasks requiring 
the services of a particular system task, DSR, or task scheduler. The queueing is handled by two 
routines in TXROOT. A task is queued by placing its TSB on a queue. The queue consists of a 
queue header and the linked TSBs. The header consists of two words, the first being a pointer to the 
last (newest) entry in the queue; and the second, a pointer to the first (oldest) entry in the queue. 

5.4.3. 1 Active Queue. The active queue consists of four individual queues corresponding to 
priority levels 0-3. When a task is bid or when its time slice expires, the task is placed on the 
active queue corresponding to the task’s priority level. The task scheduler selects the oldest task 
on the highest priority queue for the next time slice, except that each priority level is weighted 
as to the number of time slices allocated to that priority level, N, before one time slice is 
allocated to the next lower priority level; i.e., queue N+1. 

5.4. 3. 2 System Task Queues. Tasks that require the services of file utility, file management, or 
the diagnostic task are suspended and placed on the required system task’s input queue. Once bid, 
the system task continues execution until its queue is empty. 

5.4. 3. 3 DSR Queue. When a DSR is busy and another I/O call is made, the task issuing the call 
is placed on the device’s queue. The queue header is located in the device information block of 
the device PDT. 

5.4.3.4 Intertask Message Queue. When a task issues a Put Data or Get Data supervisor call, the 
message is placed only on return from the queue. 

5.4.4 SUPERVISOR CALL (SVC) TABLE. The supervisor call table provides the entry points 
to the individual supervisor call processors. The SVC table consists of two parts; a list of the 
SVC code range for each block of consecutive SVC operation codes and the actual blocks of 
entry points. 

5.4.4.1 Supervisor Call Table List. The supervisor call table list, shown in figure 5-15, contains a 
four-byte entry for each noncontiguous block of SVC codes. Bytes 0-1 contain the upper and 
lower SVC code of the block, respectively. Bytes 2-3 contain the starting address of the 
supervisor call table block. The SVC table list is terminated with a zero in bytes 0-1. 

5.4.4.2 Supervisor Call Table Block. The supervisor call table block, shown in figure 5-16, 
consists of a number of words which contain the address of each SVC processor entry point. 
Each word in the block corresponds to an SVC code within the range defined by the SVC table 
list. 



UPPER SVC CODE (O+K) 

0-OWER SVC CODE (0)j^e.^ 

ADDRESS 

OF BLOCK 0 

T 


UPPER SVC CODE (M+R) 

(Lower svc code 

ADDRESS OF BLOCK (2) 

0 (END OF LIST) 


(A) 1 3689 2 


Figure S-15. Supervisor Call Table List 
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(A) 13689 3 


Figure 5-16. Supenisor Call Table Block 

5.5 PHYSICAL DISKETTE STRUCTURE 

The diskette consists of a number of physical tracks (.77 for a one-sided, single-density 
IBM-compatible diskette) with 26 sectors per track. The diskette is divided into logical units 
called allocation units. Each allocation unit consists of 6 sectors and there are 333 allocation 
units per diskette. The physical record length is the block of data read from or written to the 
diskette, at one time. The diskette is formatted with one physical record per sector. 

5.6 LOGICAL DISKETTE STRUCTURE 

The first six allocation units are reserved for system usage and the others are available for user 


files. The diskette has the following structure: 


Allocation Unit 

Sectors 

Use 

0-3 

AU 

Boot loader 

4 

0 

System information block 

4 

1 

Allocation table 

4 

2 

Bad allocation table 

5 

0-5 

Directory 

6-333 

All 

File allocation 


5.6.1 BOOT LOADER. Allocation units 0-3 contain the system boot loader (TXBOOT 
program). This program is loaded from the diskette/cassette ROM loader; in turn, it loads the 
system file. The boot loader is not required for a diskette which is to be used as a data diskette 
only; i.e., will not contain a system file. The TXBOOT program is stored in memory image 
format. The last word of each sector is a flag to the ROM loader. When the last word is not 
equal to negative one, the ROM loader loads the next sector. When it is equal to negative one, 
the ROM loader terminates and executes the TXBOOT program. TXBOOT is copied to the 
diskette in consecutive sectors beginning at physical track 0, sector 0. All of the sectors used are 
contained in allocation units 0-3. 
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5.6.2 DISC INFORMATION BLOCK. The disc information block, shown in figure 5-17, 
contains configuration data needed by the system and utilities. The format of the disc informa- 
tion block is: 

Bytes 0-31 — Disc identification field. This information is supplied by the user during disc 
initialization (BACKUP). Typically, this field contains a diskette identification name and g 
date. This field may be changed using the disk load (DL) command of SYSUTL or DSKDMP. 

Bytes 32-33 — System file address. This field contains the starting allocation unit of the file 
designated as the system file (designated by use of the SF command of SYSUTL). The field 
contians zeros if no system file has been designated. 

Bytes 34-35 — Contain an ASCII “TX” and is used to indicate that the disc was initialized. 

The backup utility examines these bytes on the output diskette before using the diskette. 

Bytes 36-37 — Reserved. 

Bytes 38-41 — Contain the four character volume name. When no volume name is used, it is 
binary 0. This field is initialized during disc initialization (BACKUP) and may be modified 
using the change volume name (CV) command of SYSUTL. 

Bytes 42-43 — Reserved for future expansion. 

5.6.3 ALLOCATION BIT MAP. The allocation bit map (allocation unit 4, sector 1) is a bit map 
used to indicate the availability of an allocation unit. A 1 in a bit position indicates that the 
allocation unit associated with that bit is allocated, llie first bit in the map (bit 0) is associated 
with allocation unit 0, the second bit (bit 1) is associated with allocation unit 1, etc. The 
allocation bit map is initialized during disc initialization to all zeros. The bits corresponding to 
the system-reserved allocation units, 0-5, unused bits- in the sector (those greater than bit 
position 332), and bits associated with bad allocation units are set to 1. 

5.6.4 BAD ALLOCATION BIT MAP. The bad allocation bit map (allocation unit 4, sector 2) is 
used to mark defective allocation units on the diskette. Utility programs use this bit map to 
determine bad units. This table is identical in size and format to the allocation table. During 
diskette initialization, when a defective allocation unit is found, the appropriate bit is set to 1 in 
both the bad allocation bit map and allocation bit map. The bit in the allocation bit map is set 
so that the allocation unit will not be used. The unused bits in the sector (those greater than bit 
position 332) are set to Is. 
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5.6.5 DIRECTORY. The directory (allocation unit 5, sectors 0-5) is used by the system to map 
file names to the physical start location of the files on the diskette. Each of the six sectors of 
the directory has space for eight files, allowing a maximum of 48 files on the diskette. Each file 
entry, as shown in figure 5-18, is 16 bytes long and has the following format: 

Bytes 0-6 — Contain the 1-7 character file name. The name is left justified in the field and 
blank filled. 

Bytes 7-9 — Contain the 1-3 character extension name. The extension is left justified and 
blank filled. This field is all blanks when the file does not have an extension. The 
combination of file and extension name uniquely define a file on the diskette. 

Bytes 10-11 — Contain the number of the starting allocation unit. 

Byte 12 — The protection code is an ASCII character U, D, or W, which defines the file as 
unprotected, delete protected, or write protected. This field is modified by the change 
protection (CP) operation of SYSUTL or under program control. 

Byte 13 — File type, is a hexadecimal number that represents the type of file. A sequential 
file has a value of 0 and a relative record file has a value of 2. 

Bytes 14-15 — Are reserved for further expansion. 

When the diskette is initialized, the directory is initialized to periods (2Ej6). When a file is created 
the file entry is placed in the first available -space in the directory. Wlien a file is deleted, the 
entry is overwritten with periods. 

5.7 LOGICAL FILE STRUCTURE 

For each file on the diskette there exists a file control block (FCB) which contains a list of 
allocation units allocated to the file, and other data. All files begin at physical record 0 of an 
allocation unit. The first physical record (0) contains the FCB. The actual file data begins at 
physical record 1 . TX990 supports two types of files, sequential and relative record. Each file type 
has a different record and file format. 




(A)1 3689S 

Figure 5-18. Directory Entry 


16 BYTES/ENTRY 
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5.7.1 SEQUENTIAL FILE 

5.7. 1.1 Record Format. A sequential logical record consists of N characters followed by an 
end-of-logical-record character. There are also control characters for end-of-physical-record, 
end-of-file, and blank compression. The characters are defined as follows: 

FF End-of-logical-record 

FE Blank compression (to be followed by a one-byte count) 

FC End-of-physical record 

FB End-of-file 


To avoid conflicts with these control characters, data characters in the range FAj^ 
be expanded to a two-character string as follows: 


Data Character 

String Expansion 

FF 

FA, 

FF 

FE 

FA, 

FE 

FD 

FA, 

FD 

FC 

FA, 

FC 

FB 

FA, 

FB 

FA 

FA, 

00 


to FFi 6 will each 


The end-of-file character will always mark the end of the physical record in which it is 
contained. 


5.7. 1.2 Sequential File Format. The first byte of each sequential file physical record contains 
the file number (positional directory entry, the same as in byte 1 of the FCB, and the second 
byte contains the sequential physical record number, modulo 256. The logical records, as 
previously described, occupy the remaining space in the physical record. The logical records may 
span physical record boundaries and will be stored in contiguous sectors. There can be multiple 
end-of-file records in a sequential file. 

5.7.2 RELATIVE RECORD FILE 

5. 7.2.1 Record Format. Relative record logical records are of fixed length. The system uses as 
many physical records as necessary to contain a logical record. The maximum size for a logical 
record is one allocation unit. There are no control characters added to the data by the operating 
system. 

5. 1.2.2 Relative Record File Format. All logical records start at the beginning of a physical 
record. Unused space within a physical record is wasted. There is no end-of-file character. The 
write pointer in the FCB is the only end-of-file indicator. Space is allocated in the file for all 
records from 0 to the last logical record written. 
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5.7. 2.3 Program File Format. The TX990 program file is a relative record file with a record size of 
256 bytes. The file is sirhilar to the DXIO program file, with the constraint that only one program 
may be installed on a TX990 program file; that is, there is only one task, with its overlays, and 
possibly one procedure. The number of overlays is limited to 255. 

The TX990 program file is created by the link editor in image format. (See the Model 990 Com- 
puter Link Editor Reference Manual, part number 949617-9701.) The file has the format shown in 
figure 5-19. Record zero is an overhead record, whose format is shown in figure 5-20. Records 
1 and 2 form the program file directory and are described in subsequent paragraphs. The remaining 
records contain task, procedure or overlay images. Note that each segment image must start on 
a record boundary. 

The layout of the program file overhead record is: 

Bytes 0-1 — Must be zero. Indicates a program file. 

Bytes 2-1 5 — Reserved. Zero fill. 

Bytes 16-19 — Relative record number of the next available record in the image area. 

Bytes 20-5 1 — ID bit map for memory-resident tasks. Unused in TX990. 

Bytes 52-83 — ID bit map for memory-resident procedures. Unused in TX990. 

Bytes 84-1 15 — ID bit map for tasks. TX990 only uses task number 1. 

Bytes 1 16-147 — ID bit map for procedures. TX990 only Uses procedure niunber 1 . 

Bytes 148-179 — ID bit map for nonreplicative tasks. Unused in TX990. 

Bytes 180-21 1 — ID bit map for all overlays. 

Byte 212 — Maximum number of tasks. Must be one for TX990. 

Byte 213 — Offset for tasks. Unufled"hrT?C99() . 

Bytes 214-215 - Record number for start of task directory. 

RECORD 
O 

3 


OVERHEAD RECORD 


DIRECTORIES 


TASK. PROCEDURE, 
AND OVERLAY 
IMAGES 


AVAILABLE 

SPACE 


Figure 5-19. Program File Format 
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RESERVED (=0) 


NUMBER OF NEXT AVAILABLE RECORD IN IMAGE AREA 


ID BIT MAP FOR MEMORY RESIDENT TASKS 



ID BIT MAP FOR MEMORY RESIDENT PROCEDURES 


APPLICABLE 
TO SYSTEM 
PROGRAM 
FILE ONLY 


ID BIT MAP FOR ALL TASKS INSTALLED IN PROGRAM FILE 
ID BIT MAP FOR ALL PROCEDURES INSTALLED IN PROGRAM FILE 
ID BIT MAP FOR NONREPLICATI VE TASKS 

ID BIT MAP FOR ALL OVERLAYS INSTALLED IN PROGRAM FILE 

MAX NO. OF TASKS OFFSET TO TASK DIRECTORY 

RELATIVE RECORD NO. OF TASK DIRECTORY 
MAX NO. OF PROCEDURES OFFSET TO PROCEDURE DIRECTORY 

RELATIVE RECORD NO. OF PROCEDURE DIRECTORY 
MAX NO. OF OVERLAYS | OFFSET TO OVERLAY DIRECTOR^T^ 
RELATIVE RECORD NO. OF OVERLAY DIRECTORY 
MAX NO. OF AVAILABLE ENTRIES 
OFFSET TO AVAILABLE SPACE DIRECTORY 
RELATIVE RECORD NO. OF USED SPACE DIRECTORY 


(A)l 37512 


UNUSED (=0) 


Figure 5-20. Program File Overhead File 
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Byte 216 - Maximum number of procedures. Must be one for TX990. 

Byte 217 — Offset for procedures. Unused in TX990. 

Bytes 218-219 — Record number for start of procedure directory. 

Byte 220 — Maximum number of overlays. 

Byte 221 — Offset for overlays. 

Bytes 222-223 — Record number for start of overlay directory. 

Bytes 224-225 — Maximum number of holes in file. 

Bytes 226-227 — Offset for start of space directory. 

Bytes 228-229 — Record number for start of unused space directory. 

Bytes 230-255 — Unused. Set to zeros. 

The layout of the directory records is shown in figure 5-21. Data in these fields are varying lengths, 
depending on the number of tasks, procedures, and overlays-in the program file. All may be one or 
more records. 

Bytes O-(A-l) - Names of the tasks in the file. Eight ASCII bytes per name. 

Bytes A-(B-1) - Directory entries for tasks. Sixteen bytes per task. See figure 5-22A. 

Bytes B-(C-1) - Names of the procedures in the file. Eight ASCII bytes per name. 

Bytes C-(D-1) - Directory entries for procedures. Sixteen bytes per procedure. See figure 
5-22B. 

Bytes D-(E-1 ) — Names of the overlays in the file. Eight ASCII bytes per name. 

Bytes E-(F-1) — Directory entries for overlays. Sixteen bytes per overlay. See figure 5-22C. 
Bytes F-(F-H) — Number of unused directory entries in the file. 

Bytes (F-H2) - (F-t-3) — Number of records in the file. 

Bytes (F-H4) - (F+5) — Number of records available in file. 

Bytes (F+6) - (G-1) - Used space directory. Four bytes per entry. An entry for each task, 
procedure, and overlay. Unused by TX990. 

The next record is the first record of the image data. Each module is followed by a relocation bit 
map. 
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ZERO ( Z 

NAME OF TASK 1 Z ? 

ZERO 

DIRECTORY ENTRY FOR TASK 1 ■ 


NAME OF PROCEDURE 1 [ i 

ZERO ■ 

DIRECTORY ENTRY FOR PROCEDURE 1 


NAME OF OVERLAY 1 


NAME OF OVERLAY 2 


NAME OF OVERLAY 3 


NAME OF OVERLAY 255 


DIRECTORY ENTRY FOR OVERLAY 1 


DIRECTORY ENTRY FOR OVERLAY 2 


DIRECTORY ENTRY FOR OVERLAY 3 


DIRECTORY ENTRY FOR OVERLAY 255 


UNUSED SPACE DIRECTORY 



Figure 5-21. Program File Directory 
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task procedure overlay 


0 

LENGTH 

♦ 

0 

LENGTH 

0 

LENGTH j 

2 

FLAGS 


2 

FLAGS 


2 

FLAGS 

1 

4 

RECOR 

D NO. 

4 

RECORD NO. 

4 

RECORD NO. 

6 

DATE INSTALLED 

6 

DATE INSTALLED 

6 

DATE INSTALLED 

8 

LOAD ADDRESS 

8 

LOAD ADDRESS 

8 

LOAD ADDRESS 


OVLY 






OVLY 

TASK 

10 

LINK 

PRIORITY 

1 0 



10 

LINK 

ID 

1 2 

PROC1 

NOT 

12 

NOT USED (=0) 

12 




ID 

USED 














wrvr iiQFn 1 

1 4 

PARTI TION 

♦ 

1 4 



14 




SIZE 








ABC 


(A)13751 4 


•IF PARTITION SIZE =0, LENGTH FROM 
BYTES 0-t IS USED. 


Figure 5-22. Directory Entry Format 



The task directory entry data is: 

Bytes 0-1 — Length of the task segment in bytes. 
Byte 2 — Flags. When set indicate: 


BitO 

Privileged. 

Bit 1 

System. 

Bit 2 

Memory resident. 

Bits 

Delete protected. 

Bit 4 

Replicative. 

Bits 5-7 Unused. 


Bytes 3-5 — Record number. File record number of the start of the task image. 
Bytes 6-7 — Date installed. Date is in the format: 

Bits 0-6 Year displacement from 1900. 

Bits 7-15 Date. 
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Bytes 8-9 - Load address. 

Byte 10 — Overlay link. The overlay number of the first overlay associated with the task. Each 
overlay directory entrj' is in turn linked to the next entry so tasks can be associated with 
overlays when status or delete commands are executed. A value of 0 is used to terminate the 
list. 

Byte 1 1 — Task priority. 

Byte 12 — Procedure 1 ID. 

Byte 13 — Not used. 

Bytes 14-15 — Partition size is the size of the initial allocation for the task and overlays. 
The procedure directory entry data is: 

Bytes 0-1 — Length of the procedure segment in bytes. 

Byte 2 — Flags. When set indicate: 

Bits 0-1 — Not used (=0). 

Bit 2 — Memory resident. 

Bit 3 — Delete protected. 

Bits 4-6 — Not used (=0). 

Bit 7 — Directory entry in use. 

Bytes 3-5 — Record number (24 bits). Logical record number of the start of the procedure 
image. 

•Bytes 6-7 — Date installed. 

Bytes 8-9 — Load address. Must be on a beet boundary. 

Bytes 10-15 — Not used (=0). 

The overlay directory entry data is: 

Bytes 0-1 — Length of the overlay segment in bytes. 

Byte 2 — Flags. When set indicate: 

Bit 0 — Relocation map is present. 

Bits 1-2 — Not used (=0). 
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Bit 3 — Delete protected. 

Bits 4-6 - Not used (=0). 

Bit 7 — Directory entry is used. 

Bytes 3-5 — Record number (24 bits). Logical record number of the start of the overlay 
image. 

Bytes 6-7 — Date installed. 

Bytes 8-9 — Load address. Must be even. 

Byte 10 — Overlay link to next overlay. 

Byte 1 1 — Task ID of associated task. 

Bytes 12-15 - Not used (=0). 
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5.7.3 FILE CONTROL BLOCK (FCB). The format of the FCB, shown in figure 5-23, is as 
follows. 

Bytes 0-1 — Tlie file number (positional entry of the directory). When a file is deleted, this 
number is replaced with FFFFis to indicate that this FCB is no longer valid. 

Bytes 2-5 — “FCB*” sequence, used to verify that the record is an FCB and to enable the 
user to easily find an FCB when doing a diskette dump. 

Bytes 6-7 — Reserved for future expansion. 

Bytes 8-9 — Relative record length, the number of bytes in a logical record for a relative 
record file. This field is zero for a sequential file. 

Bytes 10-13 - Write pointer. For a sequential file, the write pointer is the end-of-media 
(i.e. the last record written in the last sub-file). The end-of-media is updated after each se- 
quential write. Any record past end-of-media cannot be accessed. Bytes 10-1 1 contain the AU 
address of the end-of-media relative to the beginning of the file. Bytes 12-13 are the physical 
record within the AU of the end-of-media. 

For a relative-record file, the write pointer is the address of the end-of-file record. End-of-file 
for a relative-record file is either the logical record where an end-of-file has been written or the 
largest-numbered logical record written, whichever occurred last. Bytes 10-13 are a 32-bit 
record number. 

Bytes 14-17 - Current pointer, only used for sequential files. This field has no meaning for 
relative-record files. The current pointer is used to maintain the current read or write 
position within a sequential file. It is the address of the next record to be read or written. 
Bytes 14-15 and bytes 16-17 are the AU record address and physical record address, 
respectively, of the next physical record to be read or written. 

Bytes 18-19 — Current byte pointer, a pointer to the beginning byte address within a 
physical record of the next logical record to be read or written. This field has no 
significance for relative record files. When the last operation before a file is closed is a write 
operation, the byte pointer is always set to 2, the first available byte of the next physical 
record. This is done to fill out the current physical record so the blocking buffer may be 
written to disc and released. If a read, backspace, or forward space occurred before closing 
the file, the byte pointer may be other than 2. In this case, the byte pointer points into the 
physical record preceding the one indicated to be the current physical record pointer by 
bytes 14-17. 

The rest of the FCB, beginning at byte 20, consists of 4-byte entries defining the blocks of 
allocation units allocated to the file. The first two bytes are the AU address of the first 
allocation unit in the block. The second two bytes are the number of contiguous allocation units 
in the block. An FFFFig in the first two bytes of an entry defines the end of the FCB. 

When a file is open, a copy of the FCB is maintained in memory. Some of the fields have a different 
meaning when in memory than when on the disc. These differences are noted in figure 5-23. 
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RESERVED 


RELATIVE RECORD LENGTH 


WRITE POINTER ~ T1W-AD&R- 
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TO 20 ON FLOPPY. 
FCBSIZ = 104 BYTES 
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TERMINATOR 


FFFF 


#0F A.U^S ALLOCATED 
SINCE FILE OPENED 


ONLY IN MEMORY 


Figure 5-23. File Control Block (FCB) 
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SECTION VI 

MODULE DESCRIPTIONS 


6.1 GENERAL 

This section provides a brief description of the function of each object module that may be in- 
cluded in the system. This description enables the user to determine the correct modules needed 
for a particular application or enables the system programmer to locate the modules which relate 
to the particular programming exercise. 

6.2 TX990 KERNAL MODULES 

6.2.1 TXROOT. TXROOT contains data and routines required for the TX990 system. Each rou- 
tine is described in table 6-1. 


Table 6-1. TXROOT Routines 


Name 


Meaning 


Data Structures 


Scheduler 

Device /File Qose Logic 

End Task/End Program Supervisor Call 
Interrupt and XOP Return Points 

Power Fail/Restart 

I/O Initialization Logic 

Supervisor Call Processor 
Fatal Error Logic 

Qock Interrupt Handler 


The data structures contained in TXROOT are those 
that are configuration independent. These structures 
include queue headers, supervisor call table, and flags. 
See also the paragraphs on TXROOT in the preceding 
section. 

Handles scheduling and execution of tasks. 

Qoses files or devices assigned to a task that is ter- 
minating. 

SVC processor for end task and end program SVCs. 

Common return area for interrupt and XOP proces- 
sors returning control to the operating system. 

Code executed when a power fail occurs, or when 
power is restored. 

Initializes VDTs and PDTs after the operating system 
is loaded or during manual restart. 

Decodes XOP 15 and calls appropriate processor. 

Entered when a CPU error is detected, or an illegal 
XOP or interrupt occurs. 

Executed on each clock interrupt. It sets the flag 
after the specified number of clock interrupts to in- 
dicate that a system-time interval has expired. 
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Table 6-1. TXROOT Routines (Continued) 

Name Meaning 

Queue and Dequeue Routines Routines to handle queueing and dequeueing of 

TSBs. 

Unsuspend Time Delay Task Unsuspends tasks that are in time delays. 

Update Time and Day Maintains system time and day counters. 

Bid Task Places tasks on the active queue to be executed. 

6.2.2 TSKFUN. TSKFUN contains a number of supervisor call processors for controlling task 
execution. The individual routines are described in table 6-2. 






Table 6-2. TSKFUN Routines 


Name 

Bid Task SVC Processor 

Get Parameters SVC Processor 
Get Own I.D. SVC Processor 
Get System Table Address SVC Processor 
Make Task Privileged SVC Processor 
Extend Time Slice SVC Processor 
Time Delay SVC Processor 

Activate Time Delay Task SVC Processor 
Change Priority SVC Processor 

Unconditional Wait SVC Processor 
Activate Waiting Task SVC Processor 
Get Time and Date SVC Processor 

Get Task Common SVC Processor 


Meaning 

This routine calls the bad track routine in TXROOT and 
places the previous task state in the SVC block. 

Moves task parameters from TSB to SVC block. 

Return I.D. of calling task in SVC block. 

Places system table address in SVC block. 

Sets privileged bit in task’s TSB. 

Resets the time slice limit counter. 

Sets task state to time delay and initializes the delay 
counter. 

Reactivates time delay task by clearing delay counter. 

Changes priority of task to priority specified in SVC 
block. 

Task state changed to unconditional wait. 

The specified waiting task is reactivated. 

The values of year, day, hour, minute, and second are 
placed in the SVC block. 

Returns address of common in SVC block. 
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6.2.3 lOSUPR. lOSUPR contains a number of routines used to process the SVC calls with code 
zero. The individual routines are described in table 6-3. 


Table 6-3. lOSUPR Routines 


Name 

I/O Call Processor 


I/O Queueing Logic 

Dummy Device I/O 
Error Exitr 

Process File I/O Call 

Process File Utility I/O Call 

GETDEV 

FNDLDT 

BZYCHK 

SETWPS 

GTDVNM 

CASTYP 

CKCALL 

WIOC 

ABTPRB, ABRTIO 
ABTPDT 


Meaning 

All zero code SVC calls enter here. This routine is 
the main driver for the I/O system. Other routines 
within lOSUPR are called for validation of LUNO, 
operation code, etc. File management, file utility, 
and the DSRs are called for further processing. 

When the desired PDT is busy, the TSB of the task 
issuing the I/O call is queued on the PDT. 

Routine called if I/O is to dummy. 

A group of entry points are provided to process 
various I/O errors. 

Sets up call and queues TSB for file management. 

Sets up call and queues TSB for file utility routine. 
Maps LDT and PDT to LUNO in I/O call. 

Maps LUNO to LDT. 

Routine checks whether or not the PDT is busy. If 
busy, the error flag and code in the PRB are set. 

Routine called by DSR to restore return context. 

This routine gets tlie internal device number for the 
specified LDT. 

This routine is called from DSR733 to place the 
cassette device type in the calling block. 

This routine validates I/O requests and performs 
open/close housekeeping. 

This is the SVC processor for the wait I/O super- 
visor call. 

This routine is the SVC processor for the abort SCB 
and abort I/O supervisor calls. 

This routine aborts the I/O for a specified PDT. 
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Table 6-3. lOSUPR Routines (Continued) 


Name Meaning 

This routine is called by a DSR when an I/O opera- 
tion has been completed and end-of-record processing 
is required. The end-of-record routine closes the de- 
vice, if it is record oriented, by clearing the TSB 
in the PDT, clears the busy flag in SCB and PDT, and 
reactivates the task if it is suspended on I/O. 

This routine is entered every system interval to check 
if a DSR is to be reentered or timed out. 

6.2.4 CNVRSN. This module contains the four numeric conversion supervisor call processors. 

I 6.2.5 MEMSVC. This module contains the supervisor call processors for Get Memory and Return 
§^. Memory in the single dynamic task system. 

6.2.6 TBUFMG. This module contains the buffer management routines. See Section V for a de- 
scription of buffer management and the buffer pool. 

B 6.2.7 TSKLDR. This module is the system task loader routine (see Section II) in the single 
dynamic task system. 

6.2.8 TITTCM. This module contains- the SVC processors for the intertask communications 
supervisor calls. Get Data and Put Data. 

6.2.9 CRTPRO. This module preprocesses the Get Character, conditional Get Character, and 
911 and 913 VDT utility SVC calls. This routine determines the device type of the LUNO or 
station number in the SVC call block and calls the appropriate processor. 

6.2.10 STA913. This module contains the keyboard interrupt handler for the 913 VDT and 
SVC processors for the Get Character SVC and the conditional Get Character SVC. CRTPRO must 
be included in a system containing STA91 3. 

6.2.11 STA911. This module contains the keyboard interrupt handler for the 911 VDT and 
SVC processors for the Get Character SVC and the conditional Get Character SVC. CRTPRO 
must be included in a system containing STA91 1 . 

6.2.12 SVC913. This module is the SVC processor for the 913 VDT utility SVC call. CRTPRO 
must be contained in a system containing SVC913. 

6.2.13 SVC911. This module is the SVC processor for the 911 VDT utility SVC call. CRTPRO 
must be included in a system containing SVC9 1 1 . 

6.2.14 EVENTK. This module contains the routines required to support the break key facility 
in TX990. 

6.2.15 DTASK. This is the diagnostic task (see Section II). 

6.2.16 TXSTRT. This routine contains the initialization code that is executed at initial program 
load, manual restart or power restart. This module may be placed after TXEND in the link causing 
it to be overlayed after initialization, conserving memory and eliminating the restart capability. 


ENDRCD 


TIMOUT 
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6.2.17 TXEND. This module contains external definitions for entry points which can be 
optionally left out of a given TX990 system. All modules linked after this module will be 
overlayed as part of the dynamic task area. 


6.2.18 STASK. This is the start task which prints the TX990 header message when the 
operating system is first loaded into memory. This task is usually overlayed by the dynamic task 
area (see Section II). 

6.2.19 IMGLDR. This module contains the routine to load programs from program files. 

D DMEMSVC. This module contains the supervisor call processors for Get Memory and 
Return Memory supervisor calls in the multiple dynamic task system. 

6.2.21 DYNTSK. This module contains the logic to build and delete the data structures for the 
installation and deletion of task and procedures in the multiple dynamic task system. 

6.2 22 DTSKLDR. This module contains the system task loader in the multiple dynamic task 


6.3 DEVICE SERVICE ROUTINES 


6.3.1 FPYDSR. This is the DSR for the diskette. The user may access a file on the diskette 
with the standard supervisor call block (SCB). To access the diskette directly requires a direct 
disc SCB (see Section 111). 


6.3.2 DSR733. This is the DSR for the 733 ASR. This DSR will handle I/O to both 
key board /printer and cassettes. 

6 3.3 KSRDSR. This is the DSR for the 733 KSR and 743 KSR. This DSR will handle I/O to 
the keyboard/printer only. 


the 913 VDT. The module STA913 must be included in the 
system it DSR913 is included. A system may contain both DSR913 and DSR911. 


^ V The module STA911 must be included in the 

system it DSR911 is included. A system may contain both DSR913 and DSR911. 


A c,^iT This IS the DSR for the serial interface line printer. The user may specify write 

I or write direct. Write ASCII allows only ASCII characters and some control characters to 
u printer. Write direct does not filter any characters from the line printer. Write direct 
should be used to make use of the special control features available on the TI line printer (model 
oil) line printer). 


6.3.7 CRDSR. This is the DSR for the card reader. 


6.3.8 DSRTTY. This is the DSR for the 33 ASR. 

6.3.9 DSRSMT. This is the DSR for the TI 5-MT digital I/O subsystem. 

6.3.10 DIGDSR. This is the DSR for the 32-input transition detection module. 
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6.3.11 FLPDSR. Tliis is the DSR for parallel interface line printers (Models 2230 and 2260). 
6.4 FILE MANAGEMENT 

File management consists of a number of modules that are grouped into a reentrant procedure 
(FMP), a task for each disc drive supported by the system, and file utility routine task (FUR). 
If files are to be supported, all of file management must be included in the system. 

6.4.1 FILE I/O SUPERVISOR CALL PROCESSOR MODULES. The file I/O SVC processor 
modules are described in table 6-4. 
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Name 

TXFMPl 

TXFMP2 

TXFMP3 

TXFMP4 

TXFMP 

FMOPEN 

FMCLOS 

FMREAD 

FMWRIT 

FMFBSP 

FMUTIL 

GETTSB 

FNDTRM 

SEMAPH 

GETTRK 


Table 6-4. File I/O SVC Processor Modules 

Meaning 

Tliis module is the data module for drive 1 . Tliis module contains the three-word 
task vector for the task associated with drive 1 and should be included in any disc 
system. 

This module is the data module for drive 2. It contans the three-word vector for 
the task associated with drive 2, and should be included in a two-, three-, or four- 
drive system. 

This module is the data module for drive 3. It contains the three-word vector for 
the task associated with drive 3, and should be included in a three- or four-drive 
system. 

This module is the data module for drive 4. This module, which contains the 
three-word vector for the task associated with drive 4, should be included in a 
four-drive system. 


This is the main driver of the file management procedure. This module decodes 
the opcodes and calls the appropriate opcode processor. 

This module contains the open, open rewind, and rewind file processors. The 
file is opened, and when needed, the file utility routine is called to auto-create the 
file. 

This routine contains the processors for close, close-unload, and close-EOF file. 
This module also contains a routine to deallocate unused allocation units to the 
system. Tire deallocation routine is also called by tlie FUR compress routine. 

This module contains the read file processor. This module issues reads to the 
DSR, performs the unblocking of physical records, and converts encoded control 
characters to tlieir decoded values. 

This module contains tire write file processor. This module performs the blocking 
of logical records, encoding of certain control characters, and calls -tire DSR to 
write the physical record. 

Tliis module contains the forward and backspace routines for diskette files. 

This routine contains a number of routines that are called by the other file man- 
agement routines. The individual routines are described below: 

Gets ne.\t TSB from file management queue. 

Finds end-of-file control block (FCB) in memory. FUR also calls this routirie. 

Routine to gain exclusive access to a resource. FUR also calls this routine. 

Maps allocation unit and record number address relative to be^nning of file into 
physical allocation unit and record. 
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Table 6-4. File I/O SVC Processor Modules (Continued) 
Name Meaning 

FMUTIL (Continued) 


NXTREC 

GETCUR 

RLOCK 

VALLDT 

WRTFCB 


Updates current pointers in file control block. 

Maps relative record number of relative -record file into allocation and record 
address relative to start of file. 

Checks if relative-record file record is locked. 

Verifies that LUNO has not already been opened by another task with exclusive 
access. 

Writes file control block to the disc. FUR also calls this routine. 


6.4.2 FILE UTILITY MODULE DESCRIPTIONS. The following modules make up the file utility 
task (FUR, task OBjJ, (see table 6-5). When a file I/O task (FMPl, FMP2, FMP3,or FMP4) is in- 
cluded in the system, all of the file utility modules must be included. When only assign and release 
LUNO operations are desired and file management is not desired, the module FURSVC must be 
included without the rest of the file utility modules. 

Table 6-5. File Utility Modules 

Name Meaning 

FURTSK (File Utility Task) Removes tasks from the file utility queue and decodes 

the operation code, then branches to the operation 
processor. Wlien the operation processor completes its 
task, it returns to FURTSK. FURTSK places the 
calling task back on the active queue and continues to 
remove tasks from the file utility queue until all 
requests are satisfied. 

FURSVC (Assign and Release LUNO) This module includes support to assign and release 

LUNOs using the SVC code 00 16 , opcodes 9 lie, 
and 93 i 6. This module also includes the super- 
visor call 15 16 support. 

Assigns a LUNO to a device or file. 

Release a LUNO from a device or file. 

Check range of a character. 

Search device name table (DNT) for a device name. 

Build a file LDT. 

Check syntax of a file name and put it into an LDT 
block. 

LDTOK Validate that a LUNO is not already assigned. 


ALSVC 

RLSVC 

ALPHA/ALPNUM 

DNTPDT 

FLDT 

SYNX 
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Table 6-5. File Utility Modules (Continued) 


Name 

FILESVC (Create, Delete, and Compress 
Files) 

CRESVC 

CREHRD 

RDINF 

WRDIR 

DFSVC 

RDFCB 

RLTRK 

SETUP 

CMSVC 

CHSVC (Change File Name and Change 
File Protection and Check File Name 
Syntax) 

NMSVC 

USVC 

wsvc 

DSVC 

SEARCH 

BED 

SYNSVC 


Meaning 

This module supports supervisor call code 00 16 , 
opcodes 90 16 , 92 16 , and 94 16 . 

BuUds an LDT-like structure with the file pathname. 

Physically create the file on the diskette. 

Reads the disc control block (DCB) and initializes tlie 
direct disc PRB. 

Writes the directory entry to the diskette. 

Delete file SVC processor. 

Read the file control block (FCB) and verify that it is 
a file control block. 

Deallocate tracks in a file control block (FCB). 

Builds an LDT structure, and searches the LDT list 
to see if the file is already opened. Then searches 
the directory for that file. 

Compresses a file by trimming off the excess alloca- 
tion units. Calls file I/O routines in FMUTIL. 

This module supports SVC 00 16 , operation codes 
95,6. 96,6, 97,6, 98 i 6, and 99,6- 

Change the name SVC processor. 

Unprotect the file SVC processor. 

Write protect the file SVC processor. 

Delete protect the file SVC processor. 

Set up the direct disc PRB and search the directory. 
Build an LDT structure for devices or files. 

Check the syntax of a file name SVC processor. 
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Table 6-5. File Utility Modules (Continued) 


Name 


Meaning’ 


ALUNIT (Allocate and Deallocate 
Allocation Units) 


This module is used by file I/O processors and by file 
utility processors. It allocates and deallocates alloca- 
tion units. 


ALUNIT 


Allocate diskette allocation units. 


RLUNIT 


Deallocate diskette allocation units. 


FNDSP 


Find contiguous blocks of allocation units. 


ALOSP 


Set the allocated allocation units bits “on” in the 
allocation bit map on the diskette. 


SERDIR (Search the Directory) This module is used by file I/O processors and by file 

utility processors. It searches the directory for a 
diskette file name. 


6.4.3- VOLUME (VOLUME NAME SUPPORT). The volume task is a file management task that 
locates volume names (table 6-6). When a LUNO assigned to a file using volume names is opened, 
the volume task reads from each disc drive searching for the volume name. When the volume name 
is located, the file management ID is placed in the LDT file management task associated with that 
drive bid. 

When volume name support is desired, the module volume must be included when the system is 
being generated. When volume name support is not included in the system and volume names are 
used in supervisor calls, an error >21, indicating a bad disc name, is returned to the calling task. 


Name 

VOLNAM 


VOLTSK 


FNDVOL 


FNVOLU 


Table 6-6. Volume Modules 
Meaning 

Whenever a file is being opened by a task, 
VOLNAM puts the task on the VOLQUE, then 
bids VOLTSK. Called by lOSUPR. 

Bid by VOLNAM. Takes tasks off VOLQUE, 
locates the volume in the diskette drive, and 
puts the task on FMPQUE and bids a file 
management task. 

Sets the semaphore FMPFLG and calls FNVOL. 
Returning from FNVOL, it clears the FMPFLG. 
Called by FURTSK modules. 

Calls FNVOL. Has the same calling interface 
as FNDVOL. Called by FURTSK modules. 


FNVOL Scans the PDT list until a disc PDT is found. 

Then it reads that diskette and compares the 
LDT’s volume name to tlie diskette’s volume 
name. Wien they compare, the file manage- 
ment ID is placed in the LDT. 
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6.5 OPERATOR COMMUNICATION PACKAGE (OCP) 

OCP consists of a number of modules which provide the operator with a means of communi- 
cating with the operating system. Four modules are required when OCP is included in the 
system; the rest can be optionally included. Each of the optional modules contains a number of 
individual command processors. 

6.5.1 OCPTSK. This module contains the data base for OCP and is a required module. 

6.5.2 OCPTBL. This module contains the entry points for each of the individual OCP command 
processors. This module is required. 

6.5.3 OCPPRC. This module is the main driver for OCP and is required. This module contains a 
number of individual routines which are described in table 6-7. 

Table 6-7. OCPPRC Routines 

Name Meaning 

OCP Read Reads command line. 

Input Record Pre-Scanner Reformats the command line to a specific format. 

Argument Manipulation Routines Routines used by individual processors to get parameters, convert 

to hex number if needed , and scan command line . 

Decode and Call Decodes next command and calls correct processor. 

Common Return Routine Provides common return and error returns for processors. 

I/O Routine Routine to handle I/O for rewind, forward space, and backspace 

processors. 
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6.5.4 OCPLRT. Optional processor in single dynamic task system to assign LUNO (ALUNO), 
release LUNO (RLUNO), e.xeciite program (LXECUTE), and load program (LPROG). The modules 
FURSVC and TSKLDR must be included also. 

6.5.5 DOCPLRT. Optional processor in multiple dynamic task system to assign LUNO (ALUNO), 
release LUNO (RLUNO), e.xecute program (EXECUTE), load program (LPROG), install task 
(ITASK), install procedure (IPROC), delete task (DTASK), and delete procedure (DPROC). The 
modules FURSVCT, DYNTSK, and TSKLDR must be included also. 

6.5.6 OCPSLD. Optional processor for debug commands: dump memory (DMEM), load memory 
(LMEM), add (ADD), subtract (SUBTRACT), jump (IMP), set breakpoint (SBKPT), and clear 
breakpoint (CBKPT). The module CNVRSN must be included also. 

6.5.7 OCPIOU. Optional processor in single dynamic task system for task status (STASK), I/O 
status (SIO), rewind (REWIND), backspace (BSPACE), and forward space (FSPACE). 

6.5.8 DOCPIOU. Optional processor in multiple dynamic task system for task status (STASK), 
procedure status (SPROC), I/O status (SIO), rewind (REWIND), backspace (BSPACE), and forward 
space (FSPACE). 

6.5.9 OCPTAD. Optional processor to install time and data (IDATE) and display time (TIME). 

6.5.10 OCPTLD. Optional processor for dump workspace (DWORK), kill task (KTASK), kill I/O 
(KIO), and trace address (TRACE). 

6.5.11 OCPEND. This module supplies dummy command table entries to satisfy references to 
processors that are not included in the system. This module is required unless all optional parts 
are included in the system. 
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Abort/Time-Out Routine 4.2.3 .2 

Active Queue 5. 4 .3.1 

WeiglUing Factors •. . 5.2.11 

Address Table, Command Word Table 4.5 

Allocation: 

Unit-Based I/O 3.3.3 

Units 5.6 

ASCII: 

Read 3. 3 .2.4, 3. 3 .3 .4 

Write 3. 3 .2. 4, 3. 3 .3 .4 

Bad Allocation Bit Map 5.6.4 

Bit Map: 

Allocation 5.6.3 

Bad Allocation 5.6.4 

Blank Compression 5.7. 1.1 

Block: 

Device Information 5.2.5 .2 

Direct Disc 3 .3. 1.1, 5.6.2 

File Control 5.7 

Keyboard Status 5.2.7 

Physical Record 3 .3 .3 .4 

Supervisor Call Table 5. 4 .4 .2 

Task Status 2.7, 4.4, 5.3.1 

Boot Loader 5.6.1 

Buffer: 

Linkage 5. 2 .3 .2 

Manager 2.2 

Pool 5.2.3 

Call: 

Block, Direct Disc 3.3. 1.1 

Get System Table Supervisor 3.2 

Handler, I/O 4.2.3 .3 

Interface, Supervisor 2.3 

Processor Modules, File I/O 

Supervisor 6.4.1 

Routines, User-Supplied Supervisor 4.4 

Supervisor 2.1 

Calls, Privileged Supervisor Section III 

Character, End-of-Logical-Record 5 .7.1 .1 

CNTROL 2.12 

CNVRSN 6.2.4 

Command: 

Modifying an OCP 4.5.1 

Module, Adding an OCP 4.5.3 

Command Word Table 4.5 

Common Exit Routine 2.1 

Communications Package, Operator 2.6, 6.5 

Compression, Blank 5. 7. 1.1 

'Control Block File 5.7 

Control Flow, TX990 Operating System 2.1 

Operator 2.6 

Program 2.10 

CRDSR 6.3.7 

CRTPRO 6.2.9 

Data: 

Disc Read Format 3.3.6 

Structures Section V 

Decoder, Interrupt 5.2.9 

DEF Directive 4.3, 4.4 

Deleted Sector, Write . .3.3.4 .4 


Device: 


Information Block. . . . . 


5.2.5 .2 

LDT 


5.2.2. 1 

Name Table 


5.2.1 

Service Routine 


4.2.3, 6.3 

Special 


4.2.1 

Device Table: 

Logical 

...... 

5.2.2 

Physical 

...... 

. .4.1, 4.2.1, 5.2.5 

Devices, Support of Nonstandard . . 

4.2 

DIGDSR 

...... 

6.3.10 

Diagnostic Task 

...... 

2.1, 2.7 

Direct Disc I/O 



3.3 

Directive: 

DEF 



4.3, 4.4 

REF 


4.4 

Directory, File Name . . . . . 



5.6.5 

Disc: 

DSR Errors 


3.3.5 

Format Restrictions. . . 


3.3 .4.5 

I/O 


3.3 

Information Block. . . . 


5.6.2 

Read Format Data. ... 


3.3.6 

Special Operations. . . . 


3.3.4 

Diskette Structure: 

Logical 


5.6 

Physical 


5.5 

DMEMSVC 


6.2.20 

DNT 


5.2.1 

DOCPIOU 


6.5.8, T4-1 

DOCPLRT 


6.5.5, T4-1 

DSR. . 


4.2.3 

Errors, Disc 


3.3.5 

Queue 


5. 4 .3 .3 

Temporary Storage . . . 


5.2.5 .3 

Workspace 


5.2.5. 1 

DSRTTY 


6.3.8 

DSR5MT 


6.3.9 

DSR733 


6.3.2 

DSR911 


6.3.5 

DSR913 


6.3.4 

DTASK 


. . 2.1,2.7,6.2.15 

DTSKLDR 


6.2.22 

DYNTSK 


6.2.21 

End-of-File 


5.7.1.1 

End-of-Logical Record Character . 

5.7. 1.1 

End-of-Physical-Record . . 


5.7. 1.1 

Error Message, ERRMSG . 


4.5 

Errors, Disc DSR 


3.3.5 

EVENTK 


6.2.14 

Exit Routine 


4.2.3.5 

Extended Operation 


. . . 2.3, 3.3.1, 4.3 

Factors, Active Queue Weighting . 

5.2.11 

FCB 


5.7 

File: 

Control Block 


5.7 

Format 

. .5.7.1.2,5.7.2.2,5.7.2.3 

I/O Supervisor Call Processor 
Modules 

6.4.1 

LDT 


5. 2.2 .2 

Management Tasks. . . . 


2.5, 6.4 
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Name Directory 5.6.5 

Program 5.7 .2 .3 

Sequential 5.7.1 

Structure Logical 5.7 

Utility: 

Module Descriptions 6.4.2 

Routine 5.2.2 

Task (FUR) 2.5 

Flags, System 5.4.2 

Floppy Disc: 

Format Restrictions S.3.4.5 

Special Operations 3.3.4 

FLPDSR 6.3.11 

FMPBUE 5.2.4 

FMPl 2.5, 6.4.2 

FMP2 2.5, 6.4.2 

FMP3 2.5, 6.4.2 

FMP4 2.5, 6.4.2 

Format: 

Program File 5.1.23 

Read 3 .3 .2.2, 3.3 .6 

Record 5 .7.1.1, 5.7.2 

Relative Record File 5.7 .2.2 

Restrictions, Floppy Disc 3.3 .4 .5 

Sequential File 5. 7. 1.2 

Write 3.3.2.3,3.3.3.3 

FPYDSR 6.3.1 

FUR 2.5, 5.2.2 

FURTSK 6.4.2 

Generation, System 4.2.1, 5.3 

CENTEX 4.2.1,4.4,5.2.11 

Get System Table Supervisor Call 3.2 

GETARG 4.5 

GETHEX 4.5 

Handler: 

I/O Call 4.2.3.3 

Unsolicited Interrupt 4.2.3.4 

Header Table 5.2.3.1 


Kernal Modules, TX990 
Keyboard Status Block. 

KSB . . ; 

KSRDSR 


5.2.7 

5.2.7 

6.3.3 


LDRDAT 29 

LDRFLG 2.9 

LDT 5.2.2 

Linkage, Buffer 5. 2.3 .2 

list, Supervisor Call Table 5.4 .4.1 

Loader: 

Routine 2.9 

System Boot 5.6.1 

Logical: 

Device Table 5.2.2 

Diskette Structure 5.6 

File Structure 5.7 

Track Specified 3. 3 .4 .3 

LPDSR 6.3.6 

LUNO 5.2.2 I 


Management: 

File 2.5, 6.4 

Manager, Buffer 2.2 

Map: 

Allocation Bit. ... : 5.6.3 

Bad Allocation Bit 5.6.4 

Memory Management 2.3 

MEMSVC 6.2.5 

Message, Error 4.5 

Module Descriptions Section VI 

Module Task Definition .....* 5.3 

Modules: 

File I/O Supervisor Call 

' Processor 6.4.1 

TX990 Kernal. ! 6.2 

Multiunit Workspace 5.2.6 


Nonstandard Devices, Support of 4.2 


I/O: 

Allocation Unit-Based 3.3.3 

Call Handler 4.2.3 .3 

Direct Disc 3.3 

Operation, lOURTN 4.5 

Supervisor Call Processor Modules, 

File 6.4.1 

Track-Based 3.3.2 

IMGLDR 2.11,6.2.19 

Information Block: 

Device 5. 2.5 .2 

Disc 5.6.2 

Initial Start Task 2.8 

Input/Output Operation 2.4 

Interface, Supervisor Call 2.3 

Interleaving, Sector 3.3.4.6 

Interrupt: 

Decoder 5.2,9 

Handler, Unsolicited 4.2.3.4 

Routine 4.2.2 

Vector Table 5.2.8 

lOSUPR 2.4, 6.2.3 


OCP 2.6, 4.5, 6.5 

OCP Command: 

Adding to a Module 4.5.2 

Modifying an 4.5.1 

Module, Adding an 4.5.3 

OCPEND 4.5, 6.5.9, T4-1 | 

OCPIOU 6.5.6,T4-1 | 

OCPLRT 6.5.4,T4-1 I 

OCPPRC 2.6, 4.5, 6.5.3, T4-1 I 

OCPSLD 6.5.5, T4-1 I 

OCPTAD 6.5.7, T4-1 

OCPTBL 4.5, 6.5.2, T4-1 

OCPTLD 6.5.8, T4-1 

OCPTSK 4.5, 6.5.1, T4-1 

Operating System Control Flow 2.1 

Operations: 

Extended 2.3 

Floppy Disc Special 3.3.4 

Input/Output 2.4 

Operator: 

Command Processing 4.5 g 

Communications Package 2.6, 6.5 


Change 1 


Index-3 


Digital Systems Division 



944776-9701 


PC 2.7 

PDT 4.1, 4.2.1, 5.2.5 

Physical Device Table. 4.1, 4.2.1 , 5.2.5 

Physical: 

Diskette Structure 5.5 

Record Block 3.3 .3 .4 

Tracks 5.5 

Pointer, Workspace 2.7 

Power-Up/Restart Routine 4.2.3. 1 

PRB 3.3 .3 .4 

Priority, Task 2.1 

Privileged Supervisor Calls Section III 

I Program File Format 5.7 .2.3 




Queue: 

Active 5. 4 .3.1 

DSR .5, 4.3 .3 

Weighting Factors, Active 5.2.1 1 

Queues 5.4.3 

System Task 5. 4 .3 .2 


Read: 

ASCII 3. 3. 3. 4 

Direct 3.3 .2 .4 

Format 3.3 .2.2, 3.3.3 .2, 3.3.6 

Rebid Task 2.13 

Record Format 5.7.2 

REF Directive 4.4 

Register, Status 2.7 

Relative Record File Format . . .• 5.7 .2.2 

Restrictions, Floppy Disc Format 3.3 .4 .5 


Routine: 

Abort/Time-Out 4.2.3.2 

Common Exit 2.1 

Device Service 4.2.3, 6.3 

Exit 4.2.3.5 

Extended Operation 4.3 

File UtUity 5.2.2 

Interrupt 4.2.2 

Loader . 2.9 

Power-Up/Restart 4. 2 .3.1 

User-Supplied Supervisor Call 4.4 


SCB 3.3. 1.1 

Extended 3.3.1 

SD 4.2.1 

Sector: 

Interleaving 3. 3 .4 .6 

Length Specified 3.3 .4.2 

Write Deleted 3. 3 .4 .4 

Sequential File Format 5.7.1 

ST 2.7 

Start Task, Initial 2.8 

STASK 2.8,6.2.18 

Status Block: 

Keyboard 5.2.7 

I Task 2.7, 4.4, 5.3.1 

Status Register 2.7 

STA911 6.2.11 

I STA913 6.2.10 

Storage, DSR Temporary 5.2.5 .3 


Structure: 

Data Section V 

Logical : 

Diskette 5.6 

File 5.7 

Physical Diskette 5.5 

TX990 Section II 

Supervisor Call 2.1 

Get System Table 3.2 

Interface 2.3 

Privileged Section III 

Processor Modules, File I/O 6.4.1 

Routines, User-Supplied 4.4 

Table 5.4.4 

Support of Nonstandard Devices 4.2 

2.1 5.4.4 

SVC Table, User-Defined 5.2.10 

SVC911 6.2.13 

SVC913 6.2.12 

System: 

Boot Loader 5.6.1 

Control Flow, TX990 Operating 2.1 

Flags 5.4.2 

Generation 4.2.1, 5.3 

Table 5.4.1 

Supervisor Call, Get 3.2 

Task Queues 5.4.3 .2 

Table: 

Address Table, Command Word 4.5 

Block, Supervisor Call 5. 4 .4 .2 

Command Word • .4.5 

Device Name 5.2.1 

Get System 3.2 

Header 5. 2.3.1 

Interrupt Vector 5.2.8 

List, Supervisor Call 5. 4 .4.1 

Logical Device 5.2.2 

Physical Device 4.1, 4.2.1, 5.2.5 

Get System 3.2 

Header 5. 2 .3.1 

Interrupt Vector 5.2.8 

list, Supervisor Call 5.4 .4.1 

Logical Device 5.2.2 

Physical Device 4.1 , 4.2.1 , 5.2.5 

Supervisor: 

Call 5.4.4 

Call, Get System 3.2 

System 5.4.1 

User-Defined SVC 5.2.10 

Task 2.1 

Definition Module 5.3 

Diagnostic 2.1, 2.7 

Initial Start 2.8 

Priority 2.1 

Queues, System 5.4.3 .2 

Rebid 2.13. 

Scheduler 2.1, 2.2 

Status Block 2.7, 4.4, 5.3.1 

Volume Name Support 6.4.3 

TASKDF 5.2, 5.3 
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Tasks, File Management 2.5 

TBUFMG 2.2, 6.2.6 

Temporary Storage, DSR 5.2.5 .3 

Time Slice 2 2 

TITTCM 6.2.8 

Track-Based I/O 3.3.2 

Tracks, Physical 5.5 

TSB 2.4, 4.4, 5.3.1 

TSKFUN 622 

TSKLDR 627 

TXBOOT 5 6 1 

TXDATA S.2 

TXEND 5.2.8,6.2.17 

TXROOT 2.3, 5.4, 6.2.1 

TXSTRT 6.2.16 

Unsolicited Interrupt Handler 4.2.3 .4 

User-Defined SVC Table 5.2.10 

User-Supplied Supervisor Call Routines 4.4 


Vector Table, Interrupt 

VOLUME 

5.2.8 

4 

Weighting Factors, Active Queue . 

5.2.11 

Workspace: 


DSR 

5 2 5 1 

Multiunit 

5 9 6 

Pointer 

9 7 

WP 

9 7 

Write: 


ASCII 


Deleted Sector 

.... 

3 344 

Direct 

33.2.4 

Format 

. 33.23,3.33*3 

XOP 

... 9 ^ 

XOPS 

4.3 
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